January is Theme Month

In January 2009 I will be concentrating on themes and themeing.

Got a theme question, or conundrum? Let me know.

What should 2.8 bring?

Well, the inexorable drive toward the future continues with this post on the WordPress development blog about prioritising features for 2.8, and the associated survey. So I though I would take this opportunity to tell you what I think 2.8 should bring.

Widget Management

One of the options in the survey is widget management. I rated this as most important out of the available options. But it isn’t just the UI that needs attention, although it does, as my post on widget management concepts shows. If you have ever tried to do anything slightly advanced with widgets (see my widget structures plugin) then the code requirde can drive you mad.

Right now it is far too difficult to code widgets. Single widgets are easy enough, although not easy for those without coding knowledge (that is why I created the Fun with theme widgets plugin), but multiple use widgets are horrible and require a huge amount of code that you need to copy almost verbatim. It isn’t so much a feature of WordPress as a hack the developers figured out and then provided as an example.

I think that all this stuff needs to be added to the core so that a multiple use widget requires setting a single variable in the add widget function. Alternatively, or perhaps better yet, provide a widget class that you extend to make the new widget.

Finally, I think they need to consider whether widgets can be produced using something other than code. Perhaps XML that can be imported. I write about this back at the start of November - Does WordPress need a better type of widget?

Modularisation

This is the second major thing that I think WordPress needs to start doing, and I think should start doing in 2.8.

There are significant parts of WordPress that can be segregated out and put into core plugins. While these things do no harm if they are in the core and are not used it also means that you are limited to hooking into them, or rewriting them completely if you want to change them. I would like to see a system where you could copy the core plugin into user plugins, modify it, and then it would be a simple matter to make serious changes without modifying the core itself. Widgets would be a prime candidate for pluginisation as would links.

This may mean that the plugin system needs to be looked at to get the maximum performance out of it. But that is fine by me.

This is a very big project and that dovetails nicely with my feeling that they should really let 2.7 rest for a bit before replacing it. It is by far the most advanced (in terms of what users can do) system out there and I don’t think there is an immediate need to tinker with it beyond making major improvements.

Sum

WordPress has everything it needs right now. Having revamped the UI I think there is a need to step back and do the same for the underlying architecture and code. Considering where WordPress will go in the future. Should content management be the key, or better interaction with other blogs. And how about looking at which of the BuddyPress features should be plugins for WordPress as a whole.

The real things that are needed next are a focus on developers. This means modularisation, flexibility, and simplicity.

What do you think?

Monday Poll Results: How many plugins that create settings pages do you have

Yesterday I asked how many plugins you have that create admin pages. I am not surprised at the results of this as I really had no preconceived ideas about what the result would be.

Pie chart showing the results. 5 plugins - 18%, 10 plugins 18%, 6, 0, 1, 3, 4, 15+, 26 and 34 each had 9%

With the limited number of people that answered the poll it is hard to draw any conclusions; however, It is worth noting that around 60% of the votes had less than ten plugins, and that there are a few people with a massive number of plugins that generate settings pages. The highest vote was 34 although one was More than 15, which could be higher, but I doubt it though.

In general then it looks unlikely that the vertical scolling of the new WordPress menu system is going to cause any problems.

Monday Poll: How many plugins create settings pages?

2.7 Settings Menu

One of the criticisms that were levelled at the new WordPress 2.7 admin design was that the vertical menu could quite easily create vertical scrolling, when it was intended to remove it. Kaspars wrote about vertical scrolling back in October to illustrate.

Today’s Monday poll is to find out just how many extras settings pages everyone has so we can figure out whether this actually is a problem or not. Vertical scrolling isn’t a problem form me, but I only have five extra settings pages.

Adding settings to admin pages

I want to introduce you to a new function in 2.7 that might help to reduce the number of admin pages in your WordPress installation. The function allows plugin authors to extend the existing admin pages instead of creating new ones.

Here’s a quick example:

add_action('admin_init', 'add_my_settings_field');
 
function add_my_settings_field(){
 
// The fields are:
//the id the form field will use
//name to display on the page 
//callback function
//the name of the page
//the section of the page to add the field to
add_settings_field('my_field_id' , 'My Field Caption' ,
			'my_field_callback' , 'writing' , 'default');
 
//register the setting to make sure it gets checked
register_setting('writing','my_field_id');
}
 
function my_field_callback(){
 
//echo out the text field, drop down, or other type of field.			
echo '<input name="my_field_id" id="my_field_id" type="text"
 value="'.attribute_escape(get_option('my_field_id')).'" class="regular-text code" />';
 
}

In WordPress 2.7 admin pages are made of pages, sections and fields. In the above example I have added a new field to the writing page (Settings > Writing) in the default section.

This not only creates the table rows and table header for the form field, it also saves the value for you. The above code is everything you need to add the new question.

The value can be accessed again using get_option(’my_field_id’).

You could just as easily add it to the remote_publishing section, by changing the last attribute in the add_settings_field function in the example to ‘remote_publishing’.

If you take a look at the options-writing.php page in wp-admin you will see that beneath each section there is a function, do_settings_fields, that lists the page and the section in its arguments; i.e. do_settings_fields(’writing’, ‘remote_publishing’)

These tell you the settings you need to add fields in that part of the page.

I think this is a very important step in helping to reduce the clutter in WordPress, no longer will a new admin page be needed for a single setting if it could sit in an existing page.

 Page 1 of 23  1  2  3  4  5 » ...  Last »