Next was Google XML Sitemaps - Version 3.0.3.1.

Once again, there didn’t appear to be any issues with this plugin and WordPress 2.5.

One problem I did experience with this version of the plugin was getting the plugin to write the sitemap.xml file. I uploaded an empty sitemap.xml file, and tried setting the permssions with FileZilla. I tried setting them to 666 (the usual value I use with no problem). No dice. Tried 755, and 777 - and still the plugin couldn’t write the sitemap file.

I checked the comments on the plugin’s site + did a Google search - and sure enough - there were others that had had a similar problem. What you need to do is do a manual update - by clicking on the link to rebuild the sitemap manually - found on the options page.

I uploaded the latest version of Global Translator - Version 0.8.

From what I can see, there are no issues with running this plugin on WordPress 2.5.

I have been using RapidFormatter for two years - so I tend to forget what irritants RapidFormatter erradicates from new WordPress installations:

• When I first started creating themes, I used to update the stylesheet, and upload it to my server, refresh the browser …. and see no change. This used to drive me nuts, as the server cache or my browser cache was using the old version of the stylesheet. It was one of the primary reasons for seeking a solution to edit a theme format that gave much better response times, and also avoided this irritating cache issue.I have been doing some ‘quick and dirty’ quick updates to the site recently - and that damn cache is really proving to be irritating. If the format of the stylesheet looks OK in RapidForamtter, I just trust that the uploaded stylesheet will kick in within a short space of time - rather than trying to force a refresh. My server is particularly stubborn - refreshes from 2 PCs and 3 browsers fails to get it to release it’s greedy grasp of my stylesheet. Even deleting the style.css on the server fails to get it to respond. So - every now and then one of the primary reasons for creating RapidFormatter rears it’s ugly head to prompt me to keep evolving this product.
• Another minor, but always irritating issue that arises with most new installations is getting this sort of message:
  

  About a year ago I built in a process to the theme FTP process so that RapidFormatter automatically uploads an empty .htaccess and sitemap file, and then sets the file permissions. Prior to that I used to get frequent support tickets about this issue. I’ve never had a customer support ticket since implementing the feature. So - by doing the WordPress 2.5 in a step-by-step manner - I bypassed the automatic file upload feature of RapidFormatter - and guess what - the old irritating issue reemerged. Simple enough to log onto the server and set the permissions using FileZilla, but it once again made me appreciate an often-overlooked feature of RapidFormatter.

I had an out-of-date version of this plugin - dutifully informed by the plugin each time I went to the plugins page on this site. I downloaded the latest version - which the home page states is Version 2.5 compatible.

I uploaded the plugin to my test site, and everything seemed to work without any problems - so I think it is a safe addition to any WordPress 2.5 site.

I saw this when testing a fairly complex page (the RapidNicheWebsites.com home page) - which has a number of DIV tags and class / css settings.

The good news is that the Visual editor does NOT screw up your DIV tags by replacing them with P tags. However, it does remove any tags that are deemed to be invalid in any of the standard HTML tags. So - as I saw in the Enlarger plugin, a dummy attribute inserted in the IMG tag so that the plugin could intercept that tag was immediated removed bu the tinyMCE (editor) filters.

What does not get removed are the class and style attributes, as well as any attributes which are acceptable XHTML attributes for that particular HTML tag.

So - in my home page, I had <DIV align = “center”> - and the align tag got removed - apparently because the tags is being depreciated in XHTML - so is not considered valid. A simple change to <DIV style = “text-align: center”> - and my DIV tag centered - as the Visual editor did not remove the style attribute. In a similar way, class attributes are also retained.

So - if you like to add in custom formatting tags, you need to just check your code after you have saved in Visual mode. If you see that the tag attribute is being removed, create either a class or an inline style equivalent, and you should be able to have the formatting option that you want, and still do most of you editing in Visual mode - without worrying about your tags being stripped.

This is an excellent plugin - once again by Andy Staines .

I thought this would be a ‘quickie’ to test - but no such luck. Andy uses a dummy attribute in the IMG tag - which his plugin intercepts and replaces it with a javascript call that enlarges your image when you click on it. Now this worked just fine in the HTML mode, but if you just flipped once across to the Visual mode, the aggressive tinyMCE filters stripped out the dummy attribute in the IMG tag - so you lost the thumbnail / enlarge function of the plugin.

I ended up rewriting the plugin so that is is ’safe’ in either mode. I have emailed Andy with the revised code, so he should be making this available in the near future.

So - currently fixed - but only with the code that I have rewritten. Vsn 2.2 - available on Andy’s site will NOT work in WordPress 2.5 if you choose to work in the Visual mode (not that likely - you would have to be a masochist to only work in the HTML mode).

This has been painful - upgrading RNW PageManager to work with WP 2.5.

Not that the plugin failed. It’s just that a curious omission on all the Admin pages made it a lot more difficult to use this plugin.

PageManager provides a lot of site-related functionality to RNW-enabled websites. One of its functions is to enable site developers to specify the Pages or Categories that should either be listed or excluded in the top navigation menu, the sidebars, and the footer menu. This was done with simple comma-delimited lists of Page IDs - which were easily read off the Manage Pages admin page in all prior versions :

You simply had to jot down the IDs that you either wanted in or out of a particular menu, enter the comma-delimited list into the appropriate field on the PageManager options page, and you were done :

And the result - menus without any coding :

Now it’s not just RNW that uses the comma-separated lists of IDs - these are required in some of the WordPress functions - wp_list_pages and in some of the widgets‘ options pages.

Now lets take a look at the new Manage Pages list :

Some might think it is a ‘prettier’ screen, but I think this is a case of form over function:

• The main issue - the missing IDs. (The same is for Manage Posts and Manage Categories). The only place you can see the ID is as part of the link URL - visible in the status bar when you hover over the the link.
• I used to find the Create New Page a useful link - saved having to select Write | Write Page - but this is a minor omission.
• I can see a few newbie users being somewhat bemused by this screen :
  • You only see the word Edit - if you hover over Page Name, and you get taken to the Edit window if you click on the link, and
  • You see a View tooltip if you hover over the Published/Unpublished link in the Status column.

I can see the people that have made WordPress videos grinding their teeth over this revised format, as their videos now need a complete makeover …

OK - so what did this mean for the RNW PageManager plugin?

Well - pretty much a makeover as well. From one simple Options page, I have gone to a multi-tabbed options page. Part of this reflects the new style that I have adopted for formatting my plugins, and part of this is due to the need to provide picklists for the Pages and Categories - so customers can select the required IDs for the various menus.

Now this makeover isn’t perfect - in that in this release you cannot sort the IDs - which you naturally could do in a comma-separated list (relevant for both the IncludeIDs - in the Top Menu and the FooterMenu). However, it does enable to move forward with publishing new websites, and setting up menus without trying out to fathom the Page IDs from the page and category URLs displayed in the status bar.

OK - this isn’t mission critical - but it is really irritating …

A ‘feature’ of the new Admin interface is the setting of the maximum width of the display area - to 980px.

So if you’re working with a fine resolution on your laptop or PC, you have wasted screen real estate on the right hand side, and a small editing area when adding content to your posts and pages:

Now when I first started playing with WP2.5, I dived into the CSS in the wp-admin section, and manually modified the CSS file. This isn’t a great solution, as each time there is a minor upgrade to WordPress, this change will be overwritten.

Fortunately for those that either don’t want to mess with code, or want a lasting solution, there is a simple plugin that corrects the max width setting : Remove Max Width . This makes working in the post area that much easier :

Right - now that the WordPress Admin interface is starting to look and behave in the way that I like, we can get back to upgrading the plugins that extend WordPress’s features - from an end user / visitor perspective.

I‘ve never liked the WordPress menus - specifically because for you to do most functions you have two server calls before reaching the page you want - first you select the main menu - get a page refrresh, and only then can you select the sub-menu item.

An excellent plugin that I have used for at least a year is the Advanced Admin Menus plugin - one of several great WordPress plugins by Andy Staines. Well - with the changes to the menu system, that plugin could not survive without a serious rewrite.

Fortunately, Andy has quickly produced an update for Version 2.5. It doesn’t work quite the same as prior versions - in that the earlier versions simply required that you hover over the main menu item to see / select a sub-menu item. With this version, yout need click on the main menu item to get the droplist of sub-menu items - basically the same way as menus work on Windows / Mac applications. Yes - one additional click now - but you still get immediate access to the sub-menu items of any of the main menu items after that initial click - without requiring any server refreshes.

The other thing that this plugin does is that it ‘cleans up’ the somewhat messy split menu that comes with the standard WordPress 2.5. They’ve put the less-utilised items across to the right, in smaller font, and the main menu items on the left. I’ve already had one forum cry for help - as one of my customers has not yet spotted the lesser menu items on the right, and does not know where to go to configure some plugin options.

Contrast this with the neater, easier to navigate Advanced Menu …

Note two things with this improved menu :

• All the items in one menu bar - so newbies are less likely to ‘lose’ the Settings / Plugins options, and
• The one-click access to the submenu items - for any of the main menu items.

Well - this was a relief getting the updated plugin - as WordPress 2.5 is already becoming easier to use …

By far the most complex plugin is the RNW Sidebar Widgets plugin. This single plugin provides the ability to add 12 custom sidebar widgets to a theme sidebar Some of these widgets offer unique features, while others simply provide enhanced capabilities over the standard widgets issues with WordPress.

As soon as I saw the WordPress 2.5 Widgets window, I knew I was in trouble. The whole way that widgets are configured has been significantly changed from Version 2.3 to Version 2.5.

Surprisingly, the RNW Widgets plugin activated without a problem. And when I opened the Presentation | Widgets page, all the RNW widgets were listed. Even the Options page for the widgets opened. I started hoping that the WordPress team had somehow managed to enable the old style widgets to work with WP 2.5.

No such luck.

I was able to add a RNW widget to a sidebar. Even open an options form. But as soon as I tried saving the defined options, the newly added widget disappeared.

The changes basically required a rewrite of 12 widgets. During the process, I decided to make most of the widgets ‘multi-instance. What I mean by this is that many of the standard WordPress widgets are single-instance - or single-use. So - add one of these widgets to a sidebar, and then you cannot add it anywhere else. With the fact that RNW supports silo website design, it’s important to be able to uze a widget more than once in a theme.

One nice feature about the new Widgets interface is that there are no longer any droplists for multi-instance widgets. These droplists were used in earlier WordPress versions to define how many instances of that widget were required. The new widget format is such that it automatically adds a new instance of the widget each time you add the widget to one of the sidebars.

Ok - a few hours later - and we’ve only done one plugin …