techism

While working in illustrator CS3, or any of the CS series really, I’ll be chugging along and all the sudden I notice that I can’t see my outlines when I select objects. What the hell?  I can’t see outlines or selection edges in illustrator – you know, those great blue lines that let you know what’s in your selection and what aint.  Been there! In the past this used to kind of come and go and it’s super irritating.  That is, unless you know what’s going on.  If you run into this problem, there’s a simple fix.

cmd-h.

It turns out that this is a feature accessible in the view-menu called “hide edges”, accessible via cmd-h.  Of course this is right next to a much more commonly used keyset, cmd-g (for grouping).  If you find your edges are hidden and you don’t know why, you probably miskeyed the cmd-g into cmd-h and … welp…now ya know.

Themes

• Pagelines Pro
• 2011

Plugins

• Page Comments off Please – Techism / Joe Melberg
• All-in-One Event Calendar
• All in One SEO Pack
• BWP Google XML Sitemaps
• Facebook Fanbox (with CSS Support)
• Geolocation
• Scissors
• ShareThis
• WP Realtime Sitemap
• wp ecommerce

Quit it and forget it.

I have run into this problem so many times:  I’m banging away on my OSX rig doing something important in Fireworks CS3 (yeah, I know…) and I’ve got a dozen things open.  The client sent me two Word documents and a PowerPoint for the web copy.  Meanwhile I’m uploading some YouTube clips for another client, while at the same time I’ve got Illustrator open with the web assets for the self-hosted WordPress site I’m trying to finish for deadline 10 minutes away.

Quick!  Make some changes to the slices for my custom content boxes, tab over to the preview, good.   Save.  Wha-!?

“Fireworks can not save the document because an internal error has occurred.”

Desperately I tab through all the windows I have open.  Holy god…I don’t know what changes were in the last save.  I mean, I’m good about saving…usually.

I have to grit my teeth and quit fireworks – it’s hell when each window opines “…there are changes to this document that will be lost if you do not save.”  Oh cruel dialog box – taunt me no more.

It ends in heartbreak and missed deadlines.

So when it came up today, of all days, nothing else mattered to me other than outsmarting the demon roosting in my favorite graphics app.  This time, I resolved, it would be different.

After doing some searches on different things that cause this issue, I kept seeing things about font issues being at the core of it all.  I took a break and ranted to my friends about my terrible luck…When I returned it dawned on me: what if simply disabling my font-manager software would let fireworks save without dealing with any of my active fonts?

With a smirk of doubt still on my face, I right-clicked the SuitcaseFusion icon.

“Quit”

And I waited for the lil’ icon light to dim while tapping my foot impatiently.

Finally it went out, and clicked back over to Fireworks.  I tried a fast cmd-s.

Holy cmd-s!  It worked!

So I’m posting this in case anyone else out there keeps running into this and wants to try an easy fix.  You might be able to save your work, even though the error has already cropped up, by simply quitting your font-management software.  For me, closing Suitcase Fusion completely elimintated the problem and my documents could ALL be saved.

Take that Fireworks demon!  I won, you lost.

Segmenting

The images below are a pixel-accurate view of the spaces web designers consider when they segment designs.  We segment them so that the first impression is complete at a glance for our ‘least common denominator’ (the lowest supported resolution) but also takes into account a balanced look on larger screens.  Typically, the contemporary trend is to set a fixed-width for the page matching the width of your least common denominator, and all critical content should stay in that width.  Horizontal segments then flow down the screen segmented at the termination points of common screen resolutions.  Depending on the target market’s technological sophistication these points may be different.  In this example, I chose the common practice of supporting 1024 x 768 as the most common low-resolution setting in the general public.  I then added some segments for the next common size up, and have the footer still on screen for our 1080p users.  However a design can be bottomless.

Bottomless?  Does that mean scroll bars?

People are used to scroll bars now.  The more content on the home page, and links to news articles, blog posts, promotional pages, features and other highlighted content that we present the better.  This gives google and other information centered services lots of hooks to our content and pages.  Maximum connectivity of content means maximum web presence and information propagation.  This is also an easy format to update and control.

Now for some examples

Obviously this is a fake design and not intended as a hard guide for your own work which probably diverges creatively (and in good ways) from a lot of web trends.  However usability wise, we should recognize how the amorphous shape of the web browser will re-crop our work constantly, and so we should design from that awareness.  I hope this example helps underscore some of what we discussed as we move forward to better alignment of the existing designs and a fun user experience for your customers.

The three attached images attached show:

1. How the browser space can change between devices. (Click to Enlarge)

2. How a design can be overlaid on the format-logic of multiple devices.

3. An isolated design shown at maximum supported resolution.

Our friend Alex Williams over at Thermal Exposure has put together this excellent guide on using WordPress.  This is a great reference for common WordPress features and the basics of managing your content.  If you are wondering what WordPress is like, or can’t remember how to add a PDF file – then this page should be in your bookmarks.

http://www.thermalexposure.com/2011/08/01/wordpress-new-user-tutorial

Wondering where Pair networks keeps bash hidden?

I was frustrated. I had spent the weekend on a bash script for a client hosting with Pair networks and NOTHING was working properly. Their old and moldy MYSQL 5.0 required I come at a certain client-problem from a rather tedious angle that needed bash to parse a lot of lines returned from a MYSQL command-line query in somewhat sophisticated ways. My first problem was that the MYSQL commands wouldn’t run. This is because Pair actually has my MYSQL and database related things going on another machine. So to run a mysql command, I needed to add some info beyond what I needed in my dev setup:

mysql -hYOURDBSERVER.pair.com -uUSERNAME -pPASSWORD -e 'SHOW FULL PROCESSLIST;'

The important part here is your server location at the top of the mysql command. Make sure you don’t miss the -h that leads it. Without a space, you might be confused into thinking your server is hdb123.pair.com, but it’s important to note that the -h part is a flag followed by your db123.pair.com as an argument. Another note is to make sure to add a hyphen before the “e” flag on the MYSQL statement. Pair likes it hyphenated…

My next problem was a stubborn refusal from the shell at bin/sh to process arrays. Whenever I tried array-functions in the shell script, I got this error:


declare: not found


Removing the declare got past that, but then when the array was being split up, I got THIS error:


Syntax error: word unexpected (expecting ")")


Though this worked on my local box, this fails utterly in the pair environment. To work around this, we must make sure to invoke the correct shell: bash.

If you are using the generic /bin/sh path, you might discover things like arrays and executions of mysql from the bash environment aren’t working correctly. Locate the binary by typing:

which bash

Mine was here:


#!/usr/local/bin/bash


Now my shell script is running and my client is protected against a serious error that was killing her app.

I don’t know why I’m having this problem, but I noticed that a few months ago rebooting my computer meant that for some reason I couldn’t get my php sites to run on my local server. I’d poke around and try a few guesses but nothing made sense. Eventually I learned that this is probably due to a security update that requires PHP look in a new place for your connection socket for MYSQL.

Everyone says you simply need to open the correct php.ini file and make a simple change. So first off you will want to find your php.ini file: I used phpInfo() to find the location, which is the common one most OSX servers will see ( /etc/php.ini )

Open this and change this line:

mysql.default_socket = /var/mysql/mysql.sock

To this:

mysql.default_socket = /tmp/mysql.sock

And then save the file and restart apache:

$ sudo apachectl restart

This supposedly fixes the problem for most people. I was not so fortunate. Everything was still broken. What gives?

A quick look at the old phpInfo() output revealed that for some reason PHP was still looking for the old location for the connection socket. Strange, I thought to myself…but who needs a socket? I’ll just fill in login credentials and be done with it. So I added a host, user, pass, for mysql. I restarted apache and bam! – same problem, nothing was working. AT this point I thought: Ok, maybe I’m editing the wrong php.ini file?

I looked at the phpInfo() output again, and it seemed like maybe I was in the wrong file since none of my updates were working. Also I noticed a slightly contradictory output where php seemed to be telling me the ini file was in two locations…ini file location was listed as “/etc/” but the file loaded was “/private/etc/php.ini”. I opened the /private/etc/php.ini file and discovered the reason for this: These are the same file. All the changes I had made were here as well. I’d declared a host, a new socket location, and made many other minor changes that should be appearing. I checked the output again for phpInfo() – Though I’d declared a host, a new socket location, and changed all kinds of settings, the default values still appeared in this area.

So I changed some unrelated settings as a test and restarted apache: Behold…they were changed, but php had ignored ONLY the MYSQL-related settings. What gives?

I verified once more that I was in the correct file and changed a few more settings before and after the mysql section. Those sections all took, but PHP’s mysql connection settings in this php.ini file stubbornly refused to update.

After messing with this for a few hours, I STILL don’t know why I can’t update my php.ini file’s MYSQL settings…but I did find a quick work-around: Just make a symlink between the two locations if you are in a hurry.

$ sudo ln -s /tmp/mysql.sock /var/mysql/mysql.sock

That will create a shortcut to the real socket in the place that PHP is looking.

After making that symlink, everything was gold.

Good luck and happy coding!

If you are running an OSX-based web server for your testing / staging machine as I am, you have probably needed to update your PHP library to a php5.3.x build.  I’m using Entropy for this and things seemed fine on the webserver.  Most tutorials have the same information out there about getting you running with PHP5.x in Apache.  But what about when you need to execute a php script form a cron job or from a shell script, or just right from the console?   I noticed that I was getting a strange report that my date-setting was generating a fatal error whenever php tried to run from the shell:

$ php
PHP: syntax error, unexpected '(' in /private/etc/php.ini on line 998

Upon inspection, the line in question was the default date-time setting:

date_default_timezone_set('America/Los_Angeles');

Upon inpecting this further I was baffled. This runs fine in apache and the code is 100% correct php5 initialization. After a while it dawned on me: What if apache is running the right php version but my shell is running the wrong php version?

It took some research and I was eventually able to learn to fix this by editing the following file and updating the path to php5.

$ mate ~/.bash_login

Then changing this:

export PATH="/usr/local/bin:/usr/local/sbin:/usr/local/mysql/bin:$PATH"


To this:

export PATH="/usr/local/bin:/usr/local/sbin:/usr/local/mysql/bin:/usr/local/php5/bin:$PATH"


I saved the file and re-initialized it:

$ source ~/.bash_login

Now when I run php from console, I get the correct version of php running. Enjoy!