Tagged: hacks Toggle Comment Threads | Keyboard Shortcuts

  • Frankie Jarrett 8:26 am on May 25, 2012 Permalink | Reply
    Tags: , , hacks, , , ,   

    Add prefixes to WordPress post types when a theme is activated 

    Recently, I had a real problem on my hands.

    I had neglected to prefix the post type names in some of my themes, and as it turns out, so did another popular WordPress plugin. Long story short: this plugin became unusable when running my themes, and this did not make my users very happy.

    It became clear that I needed to bust out some ninja moves to overcome this dilema.

    The code below is the solution I drafted – maybe it will help you too. It’s a function that runs when the theme is in use, and rewrites the post type names in the database with any prefix you choose.

    After the theme is activated the specified post types will be renamed to: fjarrett_acme, fjarrett_foo and fjarrett_bar.

    Sadly, there is not yet a hook that will fire only when themes are activated/updated. The after_setup_theme action is a little misleading in that it fires when WordPress sets up the current theme, not when an admin activates and/or updates the current theme.

    So, it’s basically firing with every load of WordPress when the theme is active. Someone first made a patch for this 3 years ago and it looks like it’s finally being revisited.

    For that reason, this is by no means the most resource-friendly solution, but we are killing the script if the prefixed post type already exists – which requires an additional query – but this is crucial for two reasons:

    1. So we’re not attempting to update the database with every page load – after the original post types are given prefixes the database update will never run again.
    2. So other plugins/themes (like the one I was in conflict with) can be installed later, creating their blasphemous post type names, and we won’t attempt to rewrite them.

    Hopefully this is helpful to you and your project in some way. If so, please tell me about it the comments!

     

    • Pippin 12:37 pm on May 25, 2012 Permalink | Reply

      Great one man. I’m still planning to use this to fix the terrible name I used for the EDD post type.

  • Frankie Jarrett 5:23 pm on April 6, 2012 Permalink | Reply
    Tags: hacks, , ,   

    The simplest way to require/include wp-load.php 

    If you want to use WordPress functionality in a PHP file that exists outside of your WordPress installation then you need to include wp-load.php. Perhaps you could call this “hooking into WordPress”.

    Maybe you’re already using some sort of relative path method, like:

    <?php include '../../../wp-load.php'; ?>

    But this can create problems if directories change. You need a clean, dynamic way to get wp-load.php. So here is the simplest way to do it, with just two lines of code (place it at the very top of your file):

    1
2
3
4
5
6

    <?php
 
$parse_uri = explode( 'wp-content', $_SERVER['SCRIPT_FILENAME'] );
require_once( $parse_uri[0] . 'wp-load.php' );
 
?>

    Short and sweet :)

    Disclaimer: This is intended for experimental and development purposes only. It is not advised to redundantly load WordPress on live production environments. But, why?

     

    • Christial Gold 3:12 pm on July 18, 2012 Permalink | Reply

      This makes the assumtion that the WP Content folder is named wp-content. While this is true for the default install it could be named anything. This can be defined in wp_config.php itself. For my web site it is e.g. mycontent.

      • Frankie Jarrett 3:43 pm on July 18, 2012 Permalink | Reply

        Yes, that’s correct. Thanks for the feedback!

      • Grant Landram 6:08 pm on December 10, 2012 Permalink | Reply

        Having the same issue (mine is called “content”). Any fix for irregular wp-content naming or locations?

    • ikkeaviy 2:19 am on October 29, 2012 Permalink | Reply

      where will i put the code?in what file?

      • Frankie Jarrett 12:47 pm on October 29, 2012 Permalink | Reply

        Whichever file you want to load that is outside of the WordPress templates. It must be a PHP file.

    • sy 9:51 am on November 2, 2012 Permalink | Reply

      Well, that save me some time. I was trying to make wordpress functions work on an ajaxed page. Is there some kind of shortcoming/pitfall for this method as opposed to writing an ajax function in the function.php file other than what Christian Gold mentioned?

    • sy 9:53 am on November 2, 2012 Permalink | Reply

      Nevermind I read that disclaimer.

    • peyman 6:26 am on February 14, 2013 Permalink | Reply

      Thank you very much
      I am looking for this for a long time!!!!

    • Nikita 9:56 am on February 20, 2013 Permalink | Reply

      I made some simple function which can also detect path if there’s no wp-content folder.
      function wp_path() {
      if (strstr($_SERVER["SCRIPT_FILENAME"], "/wp-content/")) {
      return preg_replace("/\/wp-content\/.*/", "", $_SERVER["SCRIPT_FILENAME"]);
      }
      return preg_replace("/\/[^\/]+?\/themes\/.*/", "", $_SERVER["SCRIPT_FILENAME"]);
      }

      Usage:
      require wp_path() . "/wp-load.php";

    • MED 11:06 pm on March 17, 2013 Permalink | Reply

      Thank you very match ;)

    • Lori 5:13 pm on March 25, 2013 Permalink | Reply

      You saved my sanity when my slider-builder wasn’t loading!
      Thank you – excellent advice!

    • Daniel Lemes 11:49 pm on June 10, 2013 Permalink | Reply

      Thank you, really “short and sweet”.

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel