Mostly about my amusement

Category: Software (page 6 of 22)

Some imaginary files are alright

This is probably a case of my not reading the manual.

I use W3 Total Cache not because I get a ton of hits. I run it because it’s cool and interesting. With the current 0.9.1 version it suggests that you add to your .htaccess file a section to handle 404 for missing static files. So non-existent txt, css, jpg, etc. will just get the web server’s 404 page and save on CPU processing via WordPress PHP.

Sensible, but robots.txt  is an imaginary file for my WordPress blog.  Requests to that file get sent to index.php and the output is dynamically created. Without the exclusion, that file URL always gets 404’ed.

Easy to fix. Right above the W3TC lines just add these lines to your .htaccess file.

<IfModule mod_rewrite.c>
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^robots.txt index.php [L]
</IfModule>

The ReWriteCond is not really needed, I’m just putting it in to be complete. If a request comes in for robots.txt it will be sent to WordPress for handling.

Use WordPress child themes

Before WordPress 3.0 the default Kubrick theme was called, um, “Default”. In the support forums people would update to the latest and greatest WordPress version and become shocked when their edits to the Default theme were lost.

It’s part of the WordPress distribution. When you override the WordPress files, those get included as well. Now with 3.0 the Default theme is gone and replaced with Twenty Ten. People will still make the mistake and modify the theme directly.

It’s not necessary and by creating a few simple file and directories, using a child them on your own is easy.

I’m a fan of the Hybrid theme and have been using a child theme already. The Vigilance theme caught my eye and I thought I’d give it a try. It was even easier when I located their instructions on how to start off.

1. Start with a pristine copy

I downloaded a copy of Vigilance from the Theme Foundry website and extracted it to my wp-content/themes directory. The version on their website is 1.51 which is slightly more up to date than the version on WordPress.ORG’s site.

2. Create your child theme directory

In wp-content/themes I create a directory called mostlyharmless-vigilance and extracted the files from this zip file into it. This is outlined in The Theme Foundry’s instructions.

3. Modify the CSS on the child theme

In the child theme directory I modified the style.css and added  a few lines:

.center-ad { text-align: center; margin:10px 0 10px 0; }
ul li.widget ul li a {
 display: inline;
 padding: 0;
 background: none;
}
embed {
 background: #fff;
 border: 2px solid #eee;
 }
#wrapper {
 background-color: white;
 border: 1px solid #ccc;
 padding: 15px;
 margin: 25px;
 margin-left: auto;
 margin-right: auto;
 border-radius: 10px;
 -webkit-border-radius: 10px;
 -moz-border-radius: 10px;
}
body {
 background-color: #ecf1ef;
}

This was to do provide me a CSS class to

  1. Provide a class to center my 2 ads
  2. Modify how the sidebar links look
  3. Put a border around and embedded videos
  4. Mess with the wrapper ID
  5. And change the color of the body background.

Nothing dramatic and the rounded corners are very 2004.

4. Modify the child theme’s functions.php file

My child theme has one useful line in it like so


php
$GLOBALS['content_width'] = $content_width = 600;
?>

I use oembed to insert YouTube and Vimeo videos into my posts. By adding this line, the embeds become 600px wide when the content supports that.

5. Start modifying files (if you want to)

The Vigilance theme will display that posts featured image if it exists. I comment out that line in index.php to disable the from happening. I copied index.php from wp-content/vigilance into wp-content/mostlyharmless-vigilance and edited line 15

<div class="entry clear">
<?php if ( function_exists( 'add_theme_support' ) ) the_post_thumbnail( array(250,9999), array( 'class' => 'alignleft' ) ); ?>

and commented out the if function.

<div class="entry clear">
<?php // if ( function_exists( 'add_theme_support' ) ) the_post_thumbnail( array(250,9999), array( 'class' => 'alignleft' ) ); ?>

Next I copied the header.php file into my child directory and modified the second line DOCTYPE from strict to transitional. Some plugins I use look better in transiti0nal.

Last, I made a copyof single.php and modified it to insert my second ad.

6. Upgrades wont worry me now

The whole point of this exercise was to make changes to the Vigilance theme while not touching the Vigilance theme’s files. When an update to the parent theme comes out, I won’t have to worry about what I’ve changed.  The three files I have modified are easily determined and simple for me to support.

If you only want change the CSS, then it’s even less work and you can skip step #5.

WordPress 3.0 is gold

It’s here and it’s “Thelonious”.

Now unless you are capable of

  1. Backing up your WordPress blog completely
  2. Performing the manual upgrade by hand
  3. Capable of restoring your file and database backup 100% yourself in case something goes seriously wrong

then consider waiting before adopting WordPress 3.0 on your blog.

The 3.0 release is BIG and things will fail on some setups. At this moment, there is no reason to rush into this release.

At some point soon, yes do upgrade. Keeping current is valuable and makes your blog easier to obtain support. But for now consider waiting.

Google XML Sitemaps and WordPress Multisite

Update August 13th, 2011: I’ve switched over and am giving a new plugin a try. It’s called Better WordPress Google XML Sitemaps (with sitemapindex and Multi-site support) and so far so good.

What really convinced me to look at this one is that the guys at WP Engine added it to their Curated Plugins list. If they are giving this a try then that’s really all justification I need.

Update July 23rd, 2011: These instructions still work for the newer 3.2.5 version as well. While this simple modification is useful, I plan to switch the to the 4.0 beta.

Update: Arne has posted an early test version on the WordPress support forums here. At this stage it’s not yet ready for release. If you would like to test that version, you can support Arne’s effort by downloading and reporting any issues to him on that thread.

I’m lazy and have not yet tried the early release version. 🙂

——————————————————–

WordPress 3.0’s Multisite feature is cool and useful. The Google (XML) Sitemaps Generator plugin is also cool and useful. Unfortunately Arne Brachhold’s excellent plugin does not work with multisite blogs.

If you activate the plugin on a multisite enabled WordPress install, you get this error message.

Which is a shame, but it did not take me a long time to find a work around. My setup is using multisite with sub-domains and with the Domain Mapping plugin. These instructions are for the 3.2.4 version of the plugin.

1. Modify the plugin

Edit the file wp-content/plugins/google-sitemap-generator/sitemap.php and comment out lines 53 to 58 to look like this

//Check for 3.0 multisite, NOT supported yet!
// if((defined(‘WP_ALLOW_MULTISITE’) && WP_ALLOW_MULTISITE) || (function_exists(‘is_multisite’) && is_multisite())) {
// if(function_exists(‘is_super_admin’) && is_super_admin()) {
// add_action(‘admin_notices’, array(‘GoogleSitemapGeneratorLoader’, ‘AddMultisiteWarning’));
// }
//
// return;
// }

You can delete these lines, but I prefer to comment them out.  All this does is prevent the plugin from detecting the multisite setup and not becoming active.

2. Get your rewrite rules ready

In your blog’s .htaccess file add these lines above your WordPress rules

RewriteRule ^sitemap.xml sitemap-%{SERVER_NAME}.xml [L]
RewriteRule ^sitemap.xml.gz sitemap-%{SERVER_NAME}.xml.gz [L]

This will come in handy later.

3. Activate the plugin and set these options

Now on each of your sites in your WordPress network, activate the Google (XML) Sitemap plugin. Do not Network Activate it.

Now got to your XML-Sitemap options page and for “Location of your sitemap file” select Custom location.

In the custom location change your change the file name sitemap.xml to sitemap-yourblogservername.xml. My server name is blog.dembowski.net so I’m using sitemap-blog.dembowski.net.xml. Save the options.

Look in your WordPress installation’s root and check if you have sitemap.xml or sitemap.xml.gz. If you do then delete them both.

Now at the top of that options page, click on “rebuild the sitemap manually” and confirm that your new sitemap-yourblogservername.xml has been created.

4. Test and confirm that this worked

Now test two things. Start by pointing your browser to http://yourblogservername/sitemap.xml and then http://yourblogservername/sitemap-yourblogservername.xml. If you setup your .htaccess rewrite rules correctly, then both URLs should work.

Load up your WordPress generated robots.txt file via http://yourblogservername/robots.txt and look at the Sitemap line. Mine reads like this

User-agent: *
Disallow:

Sitemap: http://blog.dembowski.net/sitemap-blog.dembowski.net.xml.gz

I have that rewrite rule in case the default location for the sitemap is used.  When you load the sitemap via the normal location, the rewite rule sends it to the correct location. The second gziped sitemap URL is fine.

There should be no real sitemap.xml or sitemap.xml.gz files in your blog’s root directory. Instead, each sitemap file should have your virtual WordPress network names instead.

5. Rinse and repeat

Repeat this process for each site in your WordPress Network and you can continue to use this sitemap plugin. You will need to activate the plugin in each of your sites and change sitemap.xml to include the site name just as I outline in step 3.

6. The caveat

If this works for you, great! But if it doesn’t, please don’t bug Arne. If and when he makes his plugin multisite compatible, then it will be probably a better solution than this one. I’m not seeing any PHP errors or warning in my log files, but there may be reasons why this is not a good idea.

Also, when you modify your copy of a plugin in the WordPress plugin repository and that plugin is updated you will lose your edits from step 1 when you update the plugin.

In the meanwhile, I can continue to use this excellent plugin.

Converted to WordPress 3.0 Multisite

I have a few blogs and I’ve been maintaining them each one at a time. So when a new version of WordPress is released or plugins get updated, I end up repeating the same process 5 times.

WordPress 3.0 (I’m using 3.0-RC2 as of this writing) supports multisite functionality. One set of software runs multiple sites and I only need to keep on that installation up to date. Setting up the multisite was easy and I just followed the instructions here.

For the WordPress part, I opted for the sub-domain model and with main blog as my existing blog.dembowski.net with all other blogs as *.blog.dembowski.net.

On the DNS and Apache2 portions, I added to my dembowski.net zone a new wildcard entry for *.blog.dembowski.net and added a ServerAlias in my Apache2 vhost for *.blog.dembowski.net to point to blog.dembowski.net.

I then did a WXR export of my existing blogs and imported them into the new setup. My existing blogs are blogname.dembowski.net, not blogname.blogs.dembowski.net. Not a problem. Once I had the data imported, I modified my Apache2 vhosts to point to the new install and followed Otto’s domain mapping tutorial and I’m good to go.

There is some learning for me to do. Not all plugins work in the multisite setup  and I’m working out which ones can be Network Activated or need to be activated in each instance. I’ve doped out the vhost issues including SSL, so that’s not a problem. But this is new and somethings will not work as it used to.

Cool. This ought to be a lot of fun.

WordPress 3.0 menus and Hybrid theme

WordPress 3.0 beta comes with support for a customized menu system that optionally replaces the wp_page_menu with wp_nav_menu. Drag and drop menu management is a cool and useful feature. It’s like widgets only for navigation purposes.

For my WordPress blog I am using a child theme of Hybrid called WP Full Site and I’ve made some minor changes and additions. Among them I have removed the Home link and added a Subscribe link in my menu.

Modifying my functions.php file like so accomplished the deed:

add_filter('wp_page_menu', 'custom_page_nav');

function custom_page_nav( $menu ) {

    // My blog title is already clickable, why have another Home link?
    // Remove the Home link from the home page
    $zaphome = '<li class="current_page_item"><a title="Home" href="' . get_bloginfo('wpurl') . '/">Home</a></li>';
    $menu = str_replace( $zaphome ,'', $menu );

    // Remove the Home link from everywhere else
    $zaphome = '<li><a title="Home" href="' . get_bloginfo('wpurl') . '/">Home</a></li>';
    $menu = str_replace( $zaphome ,'', $menu );

    // Now add a RSS subscribe link with CSS id
    $links .= '<li id="feed"><a href="' . get_bloginfo('rss2_url') . '" title="Subscribe to the feed">Subscribe</a></li>';
    $menu = str_replace( '</ul></div>', $links . '</ul></div>', $menu );

    return $menu;
}

And I added these lines to my style.css (I am pretty sure I appropriated it from another of Patrick Daly’s themes but not sure which one):

#navigation ul li#feed {
    width: 120px;
    float: right;
    background: url(images/feed-icon.png) 100px 13px no-repeat;
 }
#navigation ul li#feed a:hover {
    background: #433B14 url(images/feed-icon.png) 100px 13px no-repeat;
 }

And that took care of that.

The upcoming Hybrid 0.8 theme is in beta and has support for the WordPress 3.0 menu system. Activating it changes the CSS styling and replaces wp_page_menu with wp_nav_menu. I wanted to give the menu system a try while keeping my modifications. It was easier than I thought.

First up, fix the CSS. With the wp_page_menu output, the menus are styled with CSS ID of navigation. This gets switched to a CSS class called menu when you use wp_nav_menu.

/* Menus */
.menu {
        background: url('library/images/nav-bg.gif') repeat-x;
        border-bottom: 1px solid #433B14;
        border-top: 1px solid #0F0F0F;
        height: 38px;
}
.menu li {
        border-left: 1px solid #262001;
        border-right: 1px solid #322a03;
}
.menu li ul li {
        border-bottom: 1px solid #433B14;
        font-style: italic;
        font-weight: normal;
        text-transform: none;
}
.menu a {
        color: #fff;
        display: block;
        font-size: 14px;
        font-weight: bold;
        line-height: 14px;
        padding: 12px 18px;
        text-decoration: none;
}
.menu a:hover {
        background: #433B14;
}
.menu li ul li a {
        background: url('library/images/nav-bg.gif') repeat-x;
        border-bottom: 1px solid #0F0F0F;
}
/* My subscribe button */
.menu ul li#feed {
        width: 120px;
        float: right;
        background: url(images/feed-icon.png) 100px 13px no-repeat;
        }
.menu ul li#feed a:hover {
        background: #433B14 url(images/feed-icon.png) 100px 13px no-repeat;
        }
.menu ul li#feed a {
        }

Tedious, but not really a big deal and I just copied the existing CSS in the child theme. I’m not very CSS savvy so there is probably an easier way to re-use the existing section.

To add my Subscribe link all I had to do was add one more filter like so.

add_filter('wp_nav_menu', 'custom_page_nav');

Now I can switch between using the new or old menu system and maintain the look and feel that I want.

WordPress 3.0 beta looking good

I’ve been using WordPress 3.0 beta for about 2 weeks and I’ve only run into one odd behavior.

When I upload or upgrade a plugin, the old plugin gets deactivated and the new plugin version gets downloaded. What is not happening is that the page is not loading up the next steps of re-activating the new version (or just recently downloaded) plugin. I did not catch this and was running without the upgraded plugin for a day or two.

I’m keeping my copies current using SVN and I’m convinced it’s my wonky setup. This server is running NGINX and PHP-FPM. I have the NGINX running as www-data and PHP-FPM running as a separate userid (why? because I can). The NGINX and PHP5 are both installed using non-Ubuntu repos.

I don’t mind this situation and I’ll get it sorted out by running the beta on another box running Apache to get an understanding of what’s going on.

Over on Otto’s blog, he discusses the idea of holding off upgrading to 3.0 when it comes out. Given the hysteria on the support forum whenever a new version comes out, I think that’s an excellent idea. What would be fun is when the 3.0 version is released, and the automatic notification does not get triggered across the globe. Instead the blog gets updated and the notification does not get triggered until 3.1 comes out.

It’s wishful thinking on my part because too many people treat their self-hosted WordPress installation as a service and not as something they are responsible for. I think the majority of WordPress.ORG users are pretty savvy but the minority sure is vocal.

While talking about WordPress, the W3 Total Cache plugin is amazing. I’m playing with it while running the beta and it appears to be speeding up my site without using a disk cache. I have used WP Super Cache but this seems approach the problem from a different angle. Instead of creating HTML static pages, it has the option to use PHP’s opcache. I’m using APC and the speed looks like it’s working. It’s a very cool idea and the implementation looks really polished.

Once WordPress 3.0 is officially released, I’ll run two test blogs on two different boxes and compare the output with and without W3 Total Cache. This way I should be able to get almost scientific results for comparison.

Yes, but how does Matt really feel?

It reads a little like a rant, but you really can’t blame him.

I’m not even going to link any of the articles because they have so many inaccuracies you become stupider by reading them.

If you’re a web host and you turn a bad file permissions story into a WordPress story, you’re doing something wrong.

via WordPress › Blog » Secure File Permissions Matter.

It’s not rocket science and the real problem is explained in detail elsewhere but can be summarized as “It’s the hosting company, Stupid!”

Which leads me to a posting on another blog. Partial blame is leveled “At WordPress for requiring that the database credentials be stored in clear-text. At WordPress again for not installing itself securely by default.”

The ignorance continues with “I also have to agree with Network Solutions that this problem can happen at any shared host site. Not only for WordPress, but for any CMS out there that store the passwords in clear-text.”

That’s just a stupid thing to say. If you are going to make a statement like that, then you need to back it up with “WordPress should have followed example X for how to store that data securely”. It sure is good to call out from the cheap seats and that’s all that blogger is doing.

The impacted users are on a shared server that’s not setup properly. Users get a pass because, well, they’re users. It’s not really the users responsibility to understand how their self hosted blog works and prevent these compromises from making the neighborhood look bad.

Network Solutions loses any credibility because instead of just saying “Yeah, we screwed up and we’re fixing it” they played the ignorant blame-the-software approach. Network Solutions is not a flash in the pan company and should hire someone who can help them overcome Web Hosting 101 issues.