If you’ve tried the above but your /wp-admin page is still blank, then proceed to the next step – disable all plugins.  Since you can’t get to your plugins admin page, you’ll have to edit your database.  In phpmyadmin, run the following sql: SELECT option_value FROM wp_options WHERE option_name = ‘active_plugins’ LIMIT 1;  Edit the row returned above and copy the value in column option_value for safe keeping.  Then delete everything from the option_value column. (Please only do this if you know what you are doing!)  Once this data is deleted, try going to /wp-admin again and see if the login screen comes up.  If it does, login and reactivate your plugins.  After reactivating all my plugins, my login screen still came up so it apparently wasn’t a specific problem with a plugin, but something else got messed up during the site transfer process.

I hope this saves another WordPress developer time and frustration.

If you are doing a new WordPress install, you will skip this first step. To move an existing site, the site path has to be changed in all instances in your database.  For instance, if WordPress was installed at www.yourdomain.com but you are moving it to www.yourdomain.com/blog, the new url in your database replacement scripts should be www.yourdomain.com/blog.  Please see Switching URLs in WordPress for database replacement scripts.

If you are doing a new instal, or moving an existing site you will need to change your .htaccess file.  Your .htaccess file should look like the following if WordPress is installed in the folder “blog”.

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /blog/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /blog/index.php [L]
</IfModule>

There are two lines that need to change, RewriteBase and RewriteRule.

Your WordPress files, including the .htaccess file, should be ftp’d to the “blog” folder in the root of your site.  After making these changes, your blog should come up at www.yourdomain.com/blog.

However, like so much in WordPress, this setting does nothing to posts and pages already created. You can either edit each Post and Page under “Discussion” and turn off “Allow trackbacks and pingbacks on this page.” or run the following SQL from phpMyAdmin:

UPDATE wp_posts SET ping_status='closed' WHERE post_status = 'publish' AND post_type = 'post';
UPDATE wp_posts SET ping_status='closed' WHERE post_status = 'publish' AND post_type = 'page';

If you have access to your theme, you can also remove this tag:

<link rel="pingback" href="<?php bloginfo( 'pingback_url' ); ?>" />

For a detailed introduction to how trackbacks and pingbacks work, please read Introduction to Blogging (Trackbacks and Pingbacks sections).

I use MeasureIt to figure out how much space I need to line things up on a page, especially when editing older sites that don’t have a set grid. MeasureIt allows you to draw a box anywhere on the screen and displays the box dimensions. It’s very useful to make sure items far apart on the page are lined up.

I also use ColorZilla which gives you the RGB and hexadecimal color of anything you hover over when it is activated. This is a very quick way to snag a color you like off another website.

Of course, Firebug is an absolute must for web developers.  I use firebug more than any other tool when developing websites.

To make sure all links within the site reference the correct full URL, I run the following MySQL updates. Be sure to switch out ‘oldurl’ with ‘newurl’ correctly. For example, if your development site url was http://unbox.me.com and you are switching to http://www.unboxinteractive.com, set ‘oldurl’ = ‘unbox.me.com’ and ‘newurl’ = ‘www.unboxinteractive.com’. Leave off the ‘http://’ on both, even if it is stored in the database, and the replacements will work correctly.

UPDATE wp_options
 SET option_value = REPLACE (
 option_value,
 'oldurl',
 'newurl')
 WHERE option_value LIKE '%oldurl%';

UPDATE wp_postmeta
 SET meta_value = REPLACE (
 meta_value,
 'oldurl',
 'newurl')
 WHERE meta_value LIKE '%oldurl%';

UPDATE wp_posts
 SET post_content = REPLACE (
 post_content,
 'oldurl',
 'newurl')
 WHERE post_content LIKE '%oldurl%';

Editing Post Excerpt Length

WordPress’ built in function to display the excerpt on a page is “the_excerpt()”. The excerpt length defaults to 55 words. To change the length to 30 words add the following code to your functions.php file:

function new_excerpt_length($length) {
    return 30;
}
add_filter('excerpt_length', 'new_excerpt_length', 999 );

The last parameter to add_filter, 999 in this instance, sets the order in which this function is executed. According to www.wordpress.org “Lower numbers correspond with earlier execution, and functions with the same priority are executed in the order in which they were added to the action. ” I had to set this to a high number or my change was overridden.

Editing “…Continue Reading” at the end of post excerpts

To change the “…Continue Reading” link at the end of post excerpts, add the following code to your functions.php file, replacing new_excerpt_more’s return string with your customized text.

function new_excerpt_more($more) {
    return '...<div><a href="'. get_permalink() . '">Read more &gt;</a></div>';
}
add_filter('excerpt_more', 'new_excerpt_more', 999);

How can we achieve this level of cohesion when designers and programmers see the world so differently? Personally, I believe web team members need a free flow of information and open minds. Designers and Programmers should understand each others’ medium and be able to adapt to requirements and limitations. Being a programmer who works frequently with designers, I started putting together a list to help designers start on the right foot when designing for the web. The web has been around for a long time and has made many strides, but it will never be print because of its interactive nature and the various ways users view sites – from different browsers, operating systems or devices.

Text and Fonts

Which brings me to my first item – there are a few things designers have to give up when they design for web. The first being widows and orphans. And I’m not talking about old ladies and parentless children, I’m talking about words at the ends of paragraphs that end up on a line of their own. I’ve been led to believe these drive designers crazy. However they are very difficult to control on a web page. Different browsers render fonts differently. Fonts can be displayed slightly larger or more spread out from browser to browser, which causes lines to break in different places. The only way to control widows and orphans is to change the text so there isn’t a word at the end of the paragraph that could potentially fall to the next line, which I don’t believe is a good option. Web content should always come before the “look” of the paragraph. Also, when you add content managed sites into the mix, it isn’t fair to impose such strict design limitations on your client who is able to change content anywhere on any page. A much better approach is to design a basic template with set styles on headings, lists, paragraphs, etc, that accommodate various sizes of copy and forget about controlling widows and orphans.

Speaking of fonts, there are only a few standard fonts we can use within HTML without using a font service. Arial/Helvetica, Times New Roman/Times and Courier New/Courier are the safest of the web-safe fonts and should be installed on everyone’s computer. Other fonts that are generally safe are Palatino, Garamond, Bookman, Avant Garde, Verdana, Georgia, Comic Sans MS, Trebuchet MS, Arial Black and Impact. If the font is not installed on the user’s computer, the site will render in the user’s default font….which hopefully is not Comic Sans. If you want to use another font outside of images (and most words, especially the navigation should not be images) you will need to use a service to render the font within the website. Google Web Fonts, WebINK and Typekit are examples of services you can use to render a font within a website. Google Web Fonts are free to use and can be downloaded and installed on your computer to use within your web design. WebINK has a free Photoshop plugin so you can use their fonts within your comps, but you’ll have to own the font to design a site using a font from Typekit. (Disclaimer: I have not tried WebINK’s plugin yet.) Before deciding on a font from any of these services, you’ll be well served to see how the font renders in different browsers. Fonts always render better on Macs than PCs so what you see on your Mac is not necessarily what the 90% of users on PCs will see. All the font services mentioned above have samples of how a font will render on different Operating Systems and browsers. Please keep in mind, if the font was not created to be rendered on screen, it can vary greatly in size and smoothness on different browsers, especially on Windows.

Design Programs

Print designers love InDesign but InDesign lets you get away with things you cannot do in HTML. In HTML, a pixel is a pixel and it cannot be sliced or divided. Widths must be defined in pixels so if your site is 960 px and you want to divide it into quarters leaving a 30px gutter, each column would be 217.5 px. But this doesn’t work on the web. You would be well served not to leave your design broken into columns of 217.5 px width and allow your programmer to figure out what to do with your left over pixels.

Colors

In HTML, colors outside of images like fonts, borders and background-colors are defined in hexadecimal. Programs like Photoshop and Fireworks automatically display the hexadecimal equivalent of colors. So far, I haven’t been able to find anything in InDesign to get the hexadecimal color equivalent without adding third party scripts. Again, it would be best to define the colors for your web programmer than make your programmer figure out the hexadecimal equivalent of the color on their un-color balanced monitors. Colors in Photoshop and Fireworks work very well on the web so if you define a color in a logo image and use the same hexadecimal color in text, the color in your image and your text will look the same on the web. Remember also that the lighter the color the more the color can shift on different monitors. You might pick a nice light blue-ish gray that complements other blues on the site, only to have that blue-ish gray render as a pinkish gray on another monitor. Usually color shifts are not terribly noticeable, but I’ve seen a couple sites that look very muddy on my monitor, but nice and bright on color balanced Mac monitors.

I’m sure this article is just the tip of the iceberg to help web designers and programmers work together in harmony. I hope it is a helpful start to bridge the gap between designers and programmers.