Musings of ErisDS » WordPress

WordPress: Migrate! Updated

ErisDS — Fri, 23 Sep 2011 06:47:20 +0000

A new version of Migrate! is now available to download from Github.

What does this fix?

A few people have reported having problems using the Migrate! script with their local setups as it constantly shows an error message saying “Your current URL is not a valid URL” much like this:

Migrate! Was originally very strict about what constituted a valid URL and was expecting something with a TLD, which of course http://localhost doesn’t have, thus making Migrate! rather unhelpful in some local environments.

This issue has has been resolved in the latest version, which can as always be obtained from Github: Download Migrate!

WordPress: Migrate! Easy WordPress Site MigrationIf you work with multiple environments (development, staging, production etc)...
Upgrading old WordPress installs – not as scary as you think!Earlier this week I received an email requesting some help...
Spotlight: WordPress Pods PluginHave you ever needed to build a website which fit...

WordPress: Migrate! Easy WordPress Site Migration

ErisDS — Fri, 07 Jan 2011 22:32:56 +0000

Note: Migrate! Was last updated 04/09/2011

If you work with multiple environments (development, staging, production etc) when building WordPress sites, you’ll know that WordPress uses hardcoded absolute URLs in the database for various tasks. There are lots of arguments as to why this is done, and whether it’s the best solution, but for now it remains quite difficult to migrate WordPress between environments.

Having worked in this way for a number of years, I’ve developed a script to help change the URL of a WordPress installation. This script, called Migrate! is now available to download.

Migrate! Essentially takes two URLs – the one you’re migrating from, and the one you’re migrating to, and replaces one with the other in all relevant parts of the database. The database queries used to do this have been actively tested in migrating sites to various production environments. The user interface and interactions are in development.

Necessary disclaimer: I take no responsibility for problems caused by the script, but you should have a backup beforehand anyway by the very nature of the script! Also.. anything you do with the script can be easily and completely reversed by switching the “from” and “to” URLS.

Why is this not a plugin?

Once WordPress’ files and database have been moved to a new URL, it is no longer possible to successfully login to and navigate around the WordPress backend without migrating the URL in the database. Therefore, the problem with having a migration script as a plugin is that the work to replace the URLs in the database would have to be done on the original install before the files and database are moved to the new server.

This means running the plugin, moving the install, and then running the plugin on the old install again if you still need it for futher development etc. In addition, many people, who don’t work with WordPress all the time, don’t realise there is a problem with migrating WordPress to a new URL until they try to do it.

So these are the main reasons for not having it as a plugin. However, there is a plugin version, which will hopefully also handle some other task involved in migrating a site, planned for the future.

Go get it

The Migrate! script has it’s own page on this site. From there you can download the plugin, find out how to contribute, log an issue in the comments and read about the latest developments.

WordPress: Migrate! UpdatedA new version of Migrate! is now available to download...
Upgrading old WordPress installs – not as scary as you think!Earlier this week I received an email requesting some help...
Spotlight: WordPress Pods PluginHave you ever needed to build a website which fit...

WordPress Automatic Upgrades – One of the pitfalls

ErisDS — Thu, 30 Dec 2010 10:43:39 +0000

This morning I woke up to announcements of a security upgrade (3.0.4) for WordPress. It is highly recommended that everyone upgrade their installs.

I set to the task of upgrading this and a couple of other websites I look after. All of my sites are on 3.0, but not all of them have seen an update since. Nevertheless I know that upgrading is usually a one click job, and even if you have a more complex setup with massive plugins or theme frameworks like thematic where the order of updating can be important, it usually goes pretty smoothly.

So I was pretty shocked when my relatively uncomplicated wedding site failed to update from 3.0.1.

Fatal error: Call to undefined function update_core() in /blah/blah/blah/wp-admin/includes/class-wp-upgrader.php on line 895

The error message I received is pretty nonsensical – the site hadn’t been hacked (either by a hacker or my keen development skills) and there’s absolutely no reason why a WordPress function should be missing. I had already upgraded my blog from 3.0.3 successfully, but I know the WP team wouldn’t release an upgrade that only worked from the latest version.

I checked permissions on my upgrade folder were set to 777 – this wasn’t the problem, although it often is when receiving errors during automatic upgrade. After a bit of digging around, turns out the error message I got is one of a few error messages that can appear when you try to automatically update but don’t have enough disk space. Pretty simple problem to solve, but not an easy one to figure out when you’re staring at the WordPress admin screen!

Turns out, another version of this error – when it gets a bit further along this process – may also kick out the following error:

Incompatible Archive.: PCLZIP_ERR_BAD_FORMAT (-10) : Unable to find End of Central Dir Record signature

Which makes a little more sense – the archive uploaded is never complete because there’s no room for the end of it.

I’ve had a scout around the internet to see if there are any other manifestations of this problem, not dug anything else up yet, but here are a few more articles on solving problems with automatic upgrades:

Upgrading old WordPress installs – not as scary as you think!Earlier this week I received an email requesting some help...
WordPress 2.8Over the weekend I updated my blog to Wordpress 2.8....
WordPress: Migrate! Easy WordPress Site MigrationIf you work with multiple environments (development, staging, production etc)...

WordPress: link_before and link_after don’t display in wp_list_pages

ErisDS — Thu, 09 Sep 2010 13:39:22 +0000

Have you ever stumbled across the issue where wp_list_pages isn’t spitting out the text you define for link_before and link_after? I came across this some time ago: one minute my lovely pipe bars ‘|’ where there, the next they weren’t. It turns out this is due to the EXTREMELY popular All in One SEO Pack plugin (if you’re not using this you should be!).

The All in One SEO Pack plugin lets you define menu labels for pages which are used instead of the page titles. It uses a filter to swap these out, and unfortunately when it swaps out the titles it also swaps out whatever text was declared for link_before and link_after. This is particularly annoying as it happens even if you don’t supply a custom menu label.

This is only a small bug in the plugin to fix, and I have provided code which will fix it to the plugin author. In the meantime, if you run into this issue there is a simple work around. Please Note: this will prevent AIOSEOP from swapping your page titles for your custom menu labels, so don’t do this if you still want to use them!!

In your template, before you use the wp_list_pages function, add the following line of code:

1	remove_filter('wp_list_pages','aioseop_list_pages'); ?>

Then afterwards add the following:

1	add_filter('wp_list_pages','aioseop_list_pages'); ?>

This temporarily disables then reenables the filter so your menu is output properly.

So all together you should end up with something like:

1
2
3
4
5
6
7

remove_filter('wp_list_pages','aioseop_list_pages');
wp_list_pages(array('title_li' => '', 'sort_column' => 'menu_order', 'depth' => 1, 'link_after' => ' / '));
add_filter('wp_list_pages','aioseop_list_pages');
?>

Hopefully this will stop other folks from going mad wondering why bits of their menu have disappeared!

Please note: I have known this issue to occur in AIOSEOP versions 1.6.6.2 > 1.6.12.1

Snippet: WordPress – Customise the Excerpt Length and More stringThese functions and hooks let you customise the output of...
Snippet: WordPress 3.0 Menus – Add a login / logout linkThe new WordPress 3.0 menu system is pretty powerful and...
WordPress: Migrate! Easy WordPress Site MigrationIf you work with multiple environments (development, staging, production etc)...

Snippet: WordPress 3.0 Menus – Add a login / logout link

ErisDS — Mon, 06 Sep 2010 13:26:30 +0000

The new WordPress 3.0 menu system is pretty powerful and provides some very interesting new options for creating menus in WordPress. Previously, I have always used wp_list_pages and a custom Walker class to provide hierarchical menus based on the page structure, but that’s a topic for another post. This super-short snippet shows you how to add a login / logout link to one of your WordPress menus.

WordPress contains some special functions for creating login and logout links: wp_login_url and wp_logout_url. They both take a string argument which is the URL you want them to redirect to after performing the login/logout action. In the example below I am adding the login / logout link to the beginning of the menu and redirecting to the home page (index.php) in both cases.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

// functions.php
function add_login_logout_link($items, $args)
{
if(is_user_logged_in())
{
$newitems = '

. wp_logout_url('index.php') .'">Logout

';
$newitems .= $items;
}
else
{
$newitems = '

. wp_login_url('index.php') .'">Login

';
$newitems .= $items;
}
return $newitems;
}
add_filter('wp_nav_menu_items', 'add_login_logout_link', 10, 2);

If the current user is logged in, they will see a logout link and vice versa. To use this snippet, copy and paste the code into your theme’s functions.php file. You can easily change it to redirect to the dashboard after login, or have the login / logout link at the end of the menu like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

// functions.php
function add_login_logout_link($items, $args)
{
if(is_user_logged_in())
{
$newitems = $items;
$newitems .= '

. wp_logout_url('index.php') .'">Logout

';
}
else
{
$newitems = $items;
$newitems .= '

. wp_login_url('wp-admin/index.php') .'">Login

';
}

return $newitems;
}
add_filter('wp_nav_menu_items', 'add_login_logout_link', 10, 2);

You can also place the login / logout link elsewhere in the menu structure. However, you need to split the menu items apart, locate the right position, insert your menu item and then stick the menu items back together again to return. An example of putting the link second is shown below:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

// functions.php
function add_login_logout_link($items, $args)
{
$newposition = 2;

// split the menu items into an array using the ending

tag
$items = explode('

',$items);

// setup our new link (without the end li tag)
if(is_user_logged_in())
{
$newlink = '

' . $args->before . '. wp_logout_url('index.php') .'">' . $args->link_before . 'Logout' . $args->link_after . '' . $args->after; // no

needed this is added later
}
else
{
$newlink = '

' . $args->before . '. wp_login_url('index.php') .'">' . $args->link_before . 'Login' . $args->link_after . '' . $args->after; // no

needed this is added later
}

$newitems = array();

// loop through the menu items, and add the new link at the right position
foreach($items as $index => $item)
{
// array indexes are always one less than the position (1st item is index 0)
if($index == $newposition-1)
{
$newitems[] = $newlink;
}
$newitems[] = $item;
}

// finally put all the menu items back together into a string using the ending

tag and return
$newitems = implode('

',$newitems);

return $newitems;
}
add_filter('wp_nav_menu_items', 'add_login_logout_link', 10, 2);

Note that in the above example, I have also used the before, after, before_link and after_link args values so that the additional link has the same display properties as the generated ones. Also the add_filter function takes 4 arguments: the “hook” or point in the code where this code should be executed, the function to be carried out, the priority (1 is executed first, 12 is executed last) and the number of arguments the function accepts. Using priority 10 means the code is executed near last.

A Note on Snippets: When customising a CMS such as WordPress it is often the simplest pieces of code which are the hardest to either find or remember. These snippets are placed here for my own reference and will hopefully be useful to others. If you find them useful or have any suggestions, please let me know.

Snippet: WordPress – Customise the Excerpt Length and More stringThese functions and hooks let you customise the output of...
Spotlight: WordPress Admin Menu – Remove “Add New” pages or posts linkBack in June I posted about tidying up the WordPress...
Snippet: WordPress Admin – Tidy Dashboard Widgets By RoleRecently I worked on a Wordpress site where I wanted...

Spotlight: WordPress Admin Menu – Remove “Add New” pages or posts link

ErisDS — Mon, 30 Aug 2010 16:37:34 +0000

Back in June I posted about tidying up the WordPress admin dashboard. Recently I got a comment on that article asking if the admin menu could be altered for different users in a similar way.

Here’s the question:

Can I lose the “add new” under Pages drop down for editors? I don’t want them to have the ability to create new pages.

I’ve played with the WordPress admin menu a bit before now. There are two global variables which allow you to add (although there are much better ways to do this) and more importantly remove items from the WordPress menu. These variables are $menu for top-level menu groups like “Posts”, “Media” and $submenu for managing the sub-level items like “Add New” or “Library”.

In this case, we only want to remove the “Add New” sub-menu item from the pages menu, so we only need to use $submenu. If you use var_dump or print_r to display the contents of $submenu you’ll see the part of the array for the “Pages” menu looks like the snippet below. It contains two entries: one for the “Pages” listing which allows you to edit pages, and one for the “Add New” link that we want to remove. Also note: for each sub-menu item there are three pieces of information: The text to show, the capability the user must have to see this link, and the relative URL for the menu item.

*Please note: all of the following will also work for posts. You will need to substitute the word “page(s)” for “post(s)” and follow the additional instructions. For other parts of the WordPress admin you’ll need to find the right URLs, sub menu items and capabilities. All code should be placed in your theme’s functions.php file. Full code example is here: functions.php [ZIP File]

// $submenu array...
'edit.php?post_type=page' =>
array
5 =>
array
0 => string 'Pages' (length=5)
1 => string 'edit_pages' (length=10)
2 => string 'edit.php?post_type=page' (length=23)
10 =>
array
0 => string 'Add New' (length=7)
1 => string 'publish_pages' (length=13)
2 => string 'post-new.php?post_type=page' (length=27)

With all this in mind, the simplest way to remove the “Add New” link from the pages menu, is to unset this part of the array before the menu is drawn. We can create a function to do this in the functions.php file, first declaring the $submenu global variable and then unsetting the bit that we don’t want. Finally we need to add our function to the admin_menu action hook so that it is called at the right time.

1
2
3
4
5
6
7
8
9
10
11

// functions.php
function modify_menu()
{
global $submenu;
unset($submenu['edit.php?post_type=page'][10]);

// for posts it should be:
// unset($submenu['edit.php'][10]);
}
// call the function to modify the menu when the admin menu is drawn
add_action('admin_menu','modify_menu');

At first glance we’ve now achieved what we set out to do – the “Add New” link is removed from the menu, however this doesn’t really solve the underlying problem. The url for adding a new page is post-new.php?post_type=page and because we haven’t changed the permissions of an editor they can still access the page. Furthermore, there is also an “Add New” link at the top of “Pages” list page – so they can also still find the page easily.

So what we really need to do, is change the capabilities of the “editor” role. In WordPress each role has a set of “capabilities” or permissions – things they are allowed to do. The capability that allows someone with the “editor” role to access the Add New Page screen is “edit_page”, however if we remove this capability we will lose the whole “Pages” menu and also stop them being able to edit pages.

There is no way to use capabilities to restrict access to the Add New Page screen without also restricting access to the Pages list & Edit page screen. However, we can stop people from being able to publish pages using the “publish_pages” capability – this means they can create pages but they won’t appear on the website. Although this isn’t a perfect solution, it seems like a good start.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// functions.php
function modify_capabilities()
{
// get the role you want to change: editor, author, contributor, subscriber
$editor_role = get_role('editor');
$editor_role->remove_cap('publish_pages');

// for posts it should be:
// $editor_role->remove_cap('publish_posts');

// to add capabilities use add_cap()
}

add_action('admin_init','modify_capabilities');

The above snippet shows a function which gets the “editor” role and removes the “publish_pages” capability. This is hooked into “admin_init” so that it is run on each admin page. Now when editors go to the Add New Page screen they will only be able to “Submit for review” not publish the page. So now we know how to both actually stop users from creating pages AND remove the sub-menu item.

Now that we’re working with capabilities, we can change our modify_menu function to do the same. Instead of completely unsetting the menu item, we can set the capability so that it only works if the user has the capability “publish_pages”. This is just a slightly nicer way to hide the menu item – you could grant one specific editor user the “publish_pages” capability and they would still be able to access the menu item.

1
2
3
4
5
6
7
8
9
10

// functions.php
function modify_menu()
{
global $submenu;
$submenu['edit.php?post_type=page'][10][1] = 'publish_pages';

// for posts it should be:
// $submenu['edit.php'][10][1] = 'publish_posts';
}
add_action('admin_menu','modify_menu');

Next let’s get rid of that pesky “Add New” button on the Pages list screen. There doesn’t seem to be a hook we can use to do this, so instead I’ve used good ol’ fashioned CSS. We check if we are on the “edit-page” screen using the $current_screen global variable and if the user has the “publish_pages” capability using the current_user_can method. Then we spit out some CSS to hide the button and hook this into admin_head to the CSS is output in a sensible place.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// functions.php
function hide_buttons()
{
global $current_screen;

if($current_screen->id == 'edit-page' && !current_user_can('publish_pages'))
{
echo '';
}

// for posts the if statement would be:
// if($current_screen->id == 'edit-post' && !current_user_can('publish_posts'))
}
add_action('admin_head','hide_buttons');

Now we have editors which cannot see the “Add New” link in the Pages menu, or the button on the Pages screen, so there’s no easy way for them to get there. Even if they are clever enough to figure out the URL they won’t actually be able to publish their pages. However if we want to go the whole hog, we can add a bit more code to redirect them from the Add New Page screen and show them an error message.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

// functions.php
function permissions_admin_redirect() {
$result = stripos($_SERVER['REQUEST_URI'], 'post-new.php?post_type=page');

// for posts result should be:
// $result = stripos($_SERVER['REQUEST_URI'], 'post-new.php');

if ($result!==false && !current_user_can('publish_pages')) {
wp_redirect(get_option('siteurl') . '/wp-admin/index.php?permissions_error=true');
}

// for posts the if statement should be:
// if ($result!==false && !current_user_can('publish_posts')) {
}

add_action('admin_menu','permissions_admin_redirect');

The above is an additional function to test the current request URI. If it matches the Add New Page screen AND the user doesn’t have the “publish_page” capability we redirect them to the admin dashboard. The dashboard URL is /wp-admin/index.php, but I’ve added permissions_error=true so that WordPress will know to show an error message.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// functions.php
function permissions_admin_notice()
{
// use the class "error" for red notices, and "update" for yellow notices
echo "

".__('You do not have permission to access that page.')."

";
}

function permissions_show_notice()
{
if($_GET['permissions_error'])
{
add_action('admin_notices', 'permissions_admin_notice');
}
}
add_action('admin_init','permissions_show_notice');

Finally, two more functions and one more action hook. The first to draw an error message / warning to the user, and the second which checks the “permissions_error” parameter and shows the error message if it is set. Now there is absolutely no way for an editor to get to the Add New Page screen, instead they will be redirected to the dashboard and shown an error.

So this all turned out to be ever-so-slightly more complicated that I expected because there is no way to distinguish between the permission to edit and the permission to add a page or post. However, like most things in WordPress with a bit of graft it’s usually possible! I hope this has been useful, if you got lost or something doesn’t make sense or you know of a better way to do this please let me know via the comments.

Code Example: All code should go into your theme’s functions.php file. You can download the complete code sample with comments right here: functions.php [ZIP File]

Resources

Snippet: WordPress Admin – Tidy Dashboard Widgets By RoleRecently I worked on a Wordpress site where I wanted...
Snippet: WordPress 3.0 Menus – Add a login / logout linkThe new WordPress 3.0 menu system is pretty powerful and...
Spotlight: WordPress Pods PluginHave you ever needed to build a website which fit...

Upgrading old WordPress installs – not as scary as you think!

ErisDS — Fri, 02 Jul 2010 12:27:38 +0000

Earlier this week I received an email requesting some help with a WordPress install that had been hacked. The site was almost 3 years old and was still running WordPress 2.2. It was quite funny getting to see and play with retro WordPress again, but it had to go.

First of all I got rid of the hack. I didn’t do much research into WP2.2 security holes or spend any time trying to work out how it was done, I ran a text search on the files for the text and links that had been injected into the page and quickly discovered some superfluous functions in the theme footer and some other files. Deleting these got rid of the problem and restored the site to normal.

To be honest, I was nervous about upgrading this blog from WordPress 2.9.2 to 3.0, the software is moving on so quickly now, so the concept of upgrading from 2.2 where there isn’t even the luxury of an upgrade button filled me with dread. I did a little research into upgrading, and put out a feeler tweet to see if anyone had experience useful tips. Someone suggested that I upgrade to 2.8 first then 2.9 and 3.0 but I decided to just go for it to start with.

Upgrading WordPress

The WordPress documentation has extensive information on upgrading WordPress.

In short, the steps involve:

Backing up all your files and database
Deactivating all plugins
Deleting your WordPress install except for the customised parts (wp-config.php, .htaccess, themes, plugins, uploads, images, and any language files)
Downloading the latest version of WordPress and unpacking.
Uploading the new WordPress files to your website
Going to wp-admin and following the instructions to run the upgrade script

The WordPress upgrade documentation goes into great detail, so I highly recommend you follow it word for word. I was very careful to follow the instructions carefully, and I’m pleased to report that the upgrade was a complete success. Not a bug, not a snag, not a hitch – easy peasy!

My Top Tips

Some additional things I recommend doing are:

Be absolutely sure to deactivate all your plugins before deleting files and starting the upgrade process
Once the upgrade process has run, check your website thoroughly before reactivating or upgrading any plugins
If all is OK, take another backup of the database and files at this point
After backing up, reactivate each plugin one-by-one testing the site thoroughly after each reactivation to ensure no bugs are caused and that the plugin provides the expected functionality.
Take note of any plugins which malfunction, see if there is an available upgrade (don’t run it yet) and deactivate the plugin until you have tested them all
Backup again! You’ve now got all the working plugins enabled and the site is almost back to normal… so backup before upgrading your plugins!
Upgrade each plugin one-by-one (and reactivate if necessary), again testing after each upgrade.
You may have to find new plugins to replace old ones which are no longer maintained, but with luck your site should now be back to normal.

WordPress Automatic Upgrades – One of the pitfallsThis morning I woke up to announcements of a security...
WordPress: Migrate! Easy WordPress Site MigrationIf you work with multiple environments (development, staging, production etc)...
WordPress 2.8Over the weekend I updated my blog to Wordpress 2.8....

Snippet: WordPress Admin – Tidy Dashboard Widgets By Role

ErisDS — Wed, 30 Jun 2010 11:30:56 +0000

Recently I worked on a WordPress site where I wanted to be able to customise the dashboard for different user roles. WordPress has the default roles of administrators, editors, authors, contributors and subscribers. It’s not too much to assume you might not want to show your editors or authors all the details of your blog posts etc and placing these short code snippets into your theme’s functions.php file will allow you to do just that.

Clearing up

Lets get rid of the incoming links widget for authors and editors and then clean up some of the other boxes for everyone:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

function tidy_dashboard()
{
global $wp_meta_boxes, $current_user;

// remove incoming links info for authors or editors
if(in_array('author', $current_user->roles) || in_array('editor', $current_user->roles))
{
unset($wp_meta_boxes['dashboard']['normal ']['core']['dashboard_incoming_links']);
}

// remove the plugins info and news feeds for everyone
unset($wp_meta_boxes['dashboard']['normal']['core']['dashboard_plugins']);
unset($wp_meta_boxes['dashboard']['side']['core']['dashboard_primary']);
unset($wp_meta_boxes['dashboard']['side']['core']['dashboard_secondary']);

}
//add our function to the dashboard setup hook
add_action('wp_dashboard_setup', 'tidy_dashboard');

Here’s a full list of how to unset each of the current default dashboard widgets:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

//Right Now - Comments, Posts, Pages at a glance
unset($wp_meta_boxes['dashboard']['normal']['core']['dashboard_right_now']);
//Recent Comments
unset($wp_meta_boxes['dashboard']['normal']['core']['dashboard_recent_comments']);
//Incoming Links
unset($wp_meta_boxes['dashboard']['normal']['core']['dashboard_incoming_links']);
//Plugins - Popular, New and Recently updated Wordpress Plugins
unset($wp_meta_boxes['dashboard']['normal']['core']['dashboard_plugins']);

//Wordpress Development Blog Feed
unset($wp_meta_boxes['dashboard']['side']['core']['dashboard_primary']);
//Other Wordpress News Feed
unset($wp_meta_boxes['dashboard']['side']['core']['dashboard_secondary']);
//Quick Press Form
unset($wp_meta_boxes['dashboard']['side']['core']['dashboard_quick_press']);
//Recent Drafts List
unset($wp_meta_boxes['dashboard']['side']['core']['dashboard_recent_drafts']);

Add your own – Private pages menu

Perhaps rather than the default information, you have other items you’d like to be on the dashboard for authors or editors etc? I often add a dashboard widget to list private pages. Here’s how:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

// function to display widget
function display_dashboard_widget()
{
//define arguments for WP_Query()
$qargs = array(
'post_type'=>'page',
'post_status'=>'private'
);
// perform the query
$q = new WP_Query();
$q->query($qargs);

// setup the content with a list
$widget_content = '

;

// execute the WP loop

while

(

have_posts

(

)

the_post

(

)

;

$widget_content

.get_permalink() .'" rel="bookmark">'. get_the_title() .'

;

endwhile

;

$widget_content

';

// return the content you want displayed
return $widget_content;
}

//function to setup widget
function add_dashboard_widgets()
{
// create a dashboard widget called "private_page_menu_dashboard_widget" with the title "Private Pages Menu" and call our display function to draw it
wp_add_dashboard_widget('private_page_menu_dashboard_widget', 'Private Pages Menu', 'display_dashboard_widget' );
}

// finally we have to hook our function into the dashboard setup using add_action
add_action('wp_dashboard_setup', 'add_dashboard_widgets');

The only problem with wp_add_dashboard_widget is that it doesn’t allow you to define where on the dashboard the widget is placed. Instead it just places the box at the bottom of the left hand side in the ['normal']['core'] array.

I want my private page menu to display at the top on the right hand side of the dashboard, so I am going to add a few more lines to add_dashboard_widgets() to shuffle the boxes around the way I want them. This will be overridden by user settings if the boxes are dragged around, but insures that my authors and editors see the box in an obvious position when they first login.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

function add_dashboard_widgets()
{
// don't forget the global to get all dashboard widgets
global $wp_meta_boxes;

// create a dashboard widget called "private_page_menu_dashboard_widget" with the title "Private Pages Menu" and call our display function to draw it
wp_add_dashboard_widget('private_page_menu_dashboard_widget', 'Private Pages Menu', 'display_dashboard_widget' );

// reorder the boxes - first save the left and right columns into variables
$left_dashboard = $wp_meta_boxes['dashboard']['normal']['core'];
$right_dashboard = $wp_meta_boxes['dashboard']['side']['core'];

// take a copy of the new widget from the left column
$my_widget = array('private_page_menu_dashboard_widget' => $left_dashboard['private_page_menu_dashboard_widget']);

// remove the new widget from the left column
unset($left_dashboard['private_page_menu_dashboard_widget']);

// use array_merge so that the new widget is pushed on to the beginning of the right column's array
$right_dashboard = array_merge($my_widget, $right_dashboard);

// finally replace the left and right columns with the new reordered versions
$wp_meta_boxes['dashboard']['normal']['core'] = $left_dashboard;
$wp_meta_boxes['dashboard']['side']['core'] = $right_dashboard;
}

I hope you find these tricks as useful as I do!

Resources

Power Tips for WordPress Template Developers: Reloaded – more cool back end optimisations, hacks and tweaks
Register Plus WordPress Plugin – customise your registration, login and admin areas
Dashboard Widgets API – more info on adding and removing dashboard widgets

Spotlight: WordPress Admin Menu – Remove “Add New” pages or posts linkBack in June I posted about tidying up the WordPress...
Snippet: WordPress 3.0 Menus – Add a login / logout linkThe new WordPress 3.0 menu system is pretty powerful and...
Snippet: WordPress – Customise the Excerpt Length and More stringThese functions and hooks let you customise the output of...

Snippet: WordPress – Customise the Excerpt Length and More string

ErisDS — Fri, 15 Jan 2010 18:17:39 +0000

These functions and hooks let you customise the output of the_excerpt() template tag. Just copy and paste into the functions.php file in your theme. This works for both posts and pages.

To change the excerpt length (how many words are output - the default is 55 words) , define a function which returns the number you want and then call it with add_filter() on the ‘excerpt_length’ filter as shown below.

1
2
3
4
5

function custom_excerpt_length($length)
{
return 20;
}
add_filter('excerpt_length', 'custom_excerpt_length');

By default excerpts which are generated by WordPress (as opposed to defined via the “Excerpt” box) have the string “[...]” You might want to turn this into a link to the post or page and/or change the dots to something like “more”. The code below does both of these things using str_replace().

1
2
3
4
5
6

function custom_excerpt_more($more)
{
global $post;
return str_replace('[...]', '.get_permalink($post->ID).'">...read more...', $more);
}
add_filter('excerpt_more', 'custom_excerpt_more');

You can change the second parameter of str_replace() to whatever you want to be displayed. I included the $post global so that I could get the permalink and make the string into a link to the post/page.

Please note these will not work if you have any plugin installed which removes the excerpt hooks. One such plugin is the Event Calendar 3 plugin. If you come across any more please let me know in the comments.

Snippet: WordPress 3.0 Menus – Add a login / logout linkThe new WordPress 3.0 menu system is pretty powerful and...
Snippet: WordPress Admin – Tidy Dashboard Widgets By RoleRecently I worked on a Wordpress site where I wanted...
WordPress: link_before and link_after don’t display in wp_list_pagesHave you ever stumbled across the issue where wp_list_pages isn't...

Spotlight: WordPress Pods Plugin

ErisDS — Sun, 28 Jun 2009 22:09:02 +0000

Please Note: This article was written about Pods CMS version 1.6.6 and you’ll find some of the bugs and issues mentioned are now resolved.

Have you ever needed to build a website which fit into the “Posts & Page” paradigm of WordPress 95%, but also needed one or two bits of extra content? I often need to build sites that have a quote/testimonial or banner image tied to individual pages & displayed in the template separately to "the_content()". This is fine in WordPress as long as it remains a one-to-one relationship as it can easily be achieved with custom fields (and check out the More Fields plugin for handling this), but achieving a one-to-many or many-to-many relationship in WordPress requires some more dramatic extension.

To my knowledge there are two plugins for doing this. Flutter and Pods.

Flutter

I started out using Flutter as I hadn’t heard of Pods but found it to be clunky, buggy & unintuitive. When editing a content type (or write panel) created by Flutter it looks as though you are in the Post or Page section depending on where you placed your new content type. This is confusing and unnecessary.

The data types provided with Flutter are quite extensive (it even includes a colour picker). However, Flutter’s image upload control is buggy and I have experienced Flutter jumping to the wrong page, crashing Firefox and losing data. All-in-all I found it to be hard to use, missing key features and lacking documentation which meant I needed something else.

Pods

In essence what Pods does is turn WordPress into Drupal. It allows you to define your own content types with multiple fields for adding data so that you can use WordPress’ admin interface and templating system to manage whatever data you want, be it just additional testimonials, or a full-blown product database. It also allows you to define templates for displaying or listing data types & to write helpers and filters to handle the entry and display of complex data.

Pods’ integration into WordPress is much cleaner, meaning that content editing is much more intuitive than in Flutter. The many options for configuring filters and helpers has lead to a slightly complex admin interface, but one that is still highly usable. Pods also has considerably more documentation than Flutter seems to, although it is still lacking in some areas.

For me, the key bit of functionality which has made me love Pods is the PICK data type. It is essentially a drop-down list control, but instead of requiring you to define the options, it allows you to choose to list out other Pods, or WordPress objects such as Posts, Pages or Users. This means you can build relationships between your content items, and that you create blocks of content for your templates by linking pods to Posts or Pages.

One piece of functionality I needed but isn’t present is the ability to use a PICK to create a drop-down list of all Posts and Pages to choose one to link to. A PICK data type can currently only list out Pages OR Posts OR Users etc, but not both. It is also not possible to list out Attachments, despite them being stored in the same table as Posts and pages.

As I needed this functionality, I decided to implement it. I have added the ability to PICK from Attachments, Posts & Pages, Posts & Attachments, Pages & Attachments, or Posts, Pages & Attachments. Only two files were modified (manage_pods.php to add options to the select, and Pods.class.php to extend the if/else and SQL statements to choose the right data).

If you would like to use my modified version of the Pods plugin, I have made it available for download. Please first download the full Pods plugin and install it. Then download the podsmodified and upload them to the wp-content/plugins/pods/core folder. I haven’t done much testing on them but it seems to work OK for me, please let me know if you have any issues & I’ll endeavour to fix them.

So, with my extension, I have found Pods to be extremely useful in several projects. It is a very powerful and ultimately usable CMS solution. However, there are still a few areas where I feel it could be improved:

The power of the PICK data type could be improved as explained above.
I also feel that PICKs could be further improved by allowing users to specify a simple “enum”-like data type
The documentation, although extremely useful, could greatly benefit from more detail & in-depth examples
The clunky image upload interface needs work Update: This is now improved as of 1.7.6
The interface is usable, but introduces new elements not present in WordPress (namely famfamfam icon buttons) – by bringing at least the content-editing interface into line with the rest of WordPress I believe this plugin will really come of age Update: The work in progress Pods UI plguin alleviates some of these issues, but not the different editor (which is my current biggest niggle)
There is currently no way to link to a Pod from a Post or Page without configuring the relationship from the Pod itself (it would be nice to be able to setup custom fields to select from Pods but not necessary as it can be done the other way around).
There appears to be a bug in the PICK > Categories option

In summary, I believe the Pods plugin to be superior to Flutter and have found it more able to suit my needs. The PICK field type, filters and helpers make for an extremely powerful and expressive CMS and Pods integrates neatly with CMS so as not to confuse editors or clients, which is a key concern. I highly recommend the Pods plugin and look forward to seeing it mature as it has truly enormous potential.

Download Pods Modified! (For Pods 1.6.6)

Update! Download the new version of Pods Modified! Same functionality, but for newer versions of Pods podsmodified_1.9.1 (For Pods 1.9.1)

Spotlight: WordPress Admin Menu – Remove “Add New” pages or posts linkBack in June I posted about tidying up the WordPress...
WordPress: Migrate! Easy WordPress Site MigrationIf you work with multiple environments (development, staging, production etc)...
WordPress 2.8Over the weekend I updated my blog to Wordpress 2.8....