Multiplay Labs

tech hits and tips from Multiplay

Archive for the ‘Wordpress’ Category

Integrating Legacy PHP applications with WordPress

with 2 comments

Recently we wanted to integrate some existing legacy code into a new wordpress site we were developing. Obviously, we didn’t want to have to reimplement all the code for the wordpress theme separately in a standalone way just to make the two codebases visually consistent, so we looked into how to integrate the two, allowing us to make use of the wordpress theme within the new code.

This turned out to be surprisingly simple, albeit with a few caveats.

First of all, we made sure the legacy codebase had access to the wordpress installation. Next, in our main include in the legacy code (a setup/config script known to always be included), we added the following code:

require( "{$_SERVER['DOCUMENT_ROOT']}/wordpress/wp-load.php" );

This causes all pages in the legacy app to load the wordpress framework. Contrary to instructions on the WordPress Codex (which direct you to require wp-blog-header.php) this serves the page correctly, rather than as a wordpress 404 page. Obviously, you should adjust the require path to match your own environment.

Once this was done, in the legacy applications header and footer includes, we could use wordpress functions such as get_header() and get_footer() to include the parts of the theme we needed.

However, there are some caveats to this approach when integrating with legacy codebases. We found that the database connection of wordpress was overriding the database connection established by our legacy application. Since they had different permissions, the legacy application failed to perform any of it’s queries. A quick hack of resetting the connection back to the app after rendering the header, then restoring the wordpress connection prior to rendering the future fixes this. Obviously the correct solution is to update the legacy app to use a specific database connection object rather than the default of the last connection established, but this isn’t always feasible for some projects due to the time/resources involved.

Written by Andrew Montgomery-Hurrell

July 11th, 2013 at 8:19 am

Posted in PHP,Wordpress

Tagged with ,

Updated contextual help in WordPress

without comments

If you’re like me and you try to be a good citizen when it comes to writing wordpress plugins, then you’ll write some contextual help/documentation for them that shows up in the appropriate places of the wordpress admin interface.

Since the wordpress 3.3.1 update however, the previous method I used of doing this resulted in the help permanently appearing on the pages in question. When you have a lot of plugins and a lot of help text, that can result in the actual admin interface being several full page scrolls away, which can be pretty annoying.

As such, I recently worked out how to quickly adapt the old simple style of adding contextual help to make use of the newer system.

Before:

// add some contextual help in for add/edit post admin pages
add_action('load-post-new.php', 'myplugin_help');
add_action('load-post.php', 'myplugin_help');
 
function myplugin_help() {
   add_filter('contextual_help','load_myplugin_help');
}
 
function load_myplugin_help($help) {
    echo $help;
    echo "My custom plugin help";
}

After:

// add some contextual help in for add/edit post admin pages
add_action('load-post-new.php', 'myplugin_help');
add_action('load-post.php', 'myplugin_help');
 
function myplugin_help() {
   add_filter('contextual_help','load_myplugin_help');
}
 
function load_myplugin_help($help) {
    get_current_screen()->add_help_tab( array(
        'id'        => 'myplugin-help',
        'title'     => __('My Plugin Help'),
        'content'   => "Help for my plugin"
    ) );
}

The benefit of this new way is that the new system nicely sorts all the help into little menus, so rather than having all of your help on one massive page, the help dropdown at the top of the admin interface provides a menu for each plugin, allowing the help section to take up less space and generally be more usable.

Written by Andrew Montgomery-Hurrell

January 16th, 2012 at 2:56 pm

Posted in Code,PHP,Wordpress

Tagged with

WordPress v3.0 breaks pagination for sites with category in their permalinks

without comments

Unfortunately WordPress v3.0 breaks post pagination for sites that include category in their permalinks.

The issue is caused by a fix to wp-includes/canonical.php (r13781) that was added to fix bug #14201

The code in question is:

} elseif ( is_single() && strpos($wp_rewrite->permalink_structure, '%category%') !== false ) {
           $category = get_term_by('slug', get_query_var('category_name'), 'category');
           $post_terms = wp_get_object_terms($wp_query->get_queried_object_id(), 'category', array('fields' => 'tt_ids'));
           if ( (!$category || is_wp_error($category)) || ( !is_wp_error($post_terms) && !empty($post_terms) && !in_array($category->term_taxonomy_id, $post_terms) ) )
               $redirect_url = get_permalink($wp_query->get_queried_object_id());

The problem is that get_term_by doesn’t support hierarchies so when passed a second level category e.g. cars/sports it will fail and hence the rewrite is performed loosing the page information.

The following fixes this but I’m not 100% that the intention is to only check the last category in the hierarchy, although with our data anything more would appear to fail. This may indicate that additional fixes are required but anyway:-

$category = get_term_by('slug', end( explode( '/', get_query_var('category_name') ) ), 'category') ;

For more information see WordPress Bug #13471

Written by Dilbert

June 30th, 2010 at 6:53 pm

Posted in Hackery,Wordpress