WordPress.org

Ready to get started?Download WordPress

Ideas

Add theme/plugin reference to wp_options records

  1. Misamee
    Member

    One of the most annoying task in WordPress is to keep the wp_option table as clean as possible.

    I think that if all WP functions that stores data in this table would also add information about who uses a specific option (see below for details) would help keeping clean the table.

    I'm thinking to some king of 1-n relationship (or a text field containing serialized data), as option might be used by one or more themes/plugins.

    Each time a function that reads from wp_option gets called, it must know who's is calling it (either by simply finding function caller, or requesting a specific parameter).

    Of course, the same applies when a function that writes option is called.

    When a theme or plugin is (properly) deleted, WP could take care of cleaning these options (as long as they aren't used by something else).

    Posted: 11 months ago #
  2. Ipstenu (Mika Epstein)
    Half-Elf Support Rogue & Mod

    This ability to delete is already built in to WP plugins and themes via the uninstall.php file. We do not have the ability to enforce its correct usage at this time :/

    Posted: 11 months ago #
  3. Misamee
    Member

    Ipstenu, yes, I know about uninstall.php. but no many developers use it as far as I can see.

    This often creates orphan entries in wp_options.

    I don't think any "moderator" will ever validate plugins or themes, before publishing or updating them.

    If get_option() and update_option() could take care of that (maybe with a new mandatory parameter for the plugin/theme name), this would help keeping track of which plugin (or theme) is using this option.

    Posted: 11 months ago #
  4. Ipstenu (Mika Epstein)
    Half-Elf Support Rogue & Mod

    Impractical as we would have to support legacy plugins and themes unless you think forcing all of them to update, which no. That is far too monumental and drastic to enforce. Every single theme and plugin on this planet would have to update.

    Posted: 11 months ago #
  5. Misamee
    Member

    I'm thinking more to a new functions (making the olds still valid, but deprecated) or a new optional parameter (that in future would become mandatory).

    Posted: 11 months ago #
  6. Misamee
    Member

    Even better a new class.
    Something like that:

    function get_option($option, $default = false)
    {
    	$wp_options = new wp_options();
    	return $wp_options->get_option($option, $default);
    }
    
    function update_option( $option, $newvalue )
    {
    	$wp_options = new wp_options();
    	return $wp_options->update_option($option, $newvalue);
    }
    
    class wp_options
    {
    
    	private $context;
    
    	function __construct($context = 'some_generic_context')
    	{
    		$this->context = $context;
    	}
    
    	function get_option($option, $default = false)
    	{
    		// Same as standard get_option, but storing also $context value in wpdb
    	}
    
    	function update_option( $option, $newvalue )
    	{
    		// Same as standard update_option, but checking also $context value in wpdb;
    	}
    
    	//... all other WP option functions would follow that same logic
    }
    Posted: 11 months ago #
  7. Les-Options
    Member

    12345

    Hello,
    It's true, Ipstenu, that we can't modify or ask to modify all WP themes and plugins around the world.
    So, Sciamannikoo and Ipstenu, which options to choose ?
    a : Advice new developers about including a new procedure inside plugins and themes.
    b: Develop a dedicate plugin to clean wp-option tables (maybe like the old "http://wordpress.org/plugins/clean-options/ " )

    Posted: 10 months ago #
  8. Misamee
    Member

    Again, I don't think developers would actually need to modify anything, if they don't want.

    Implementing something similar to the "mockup class" I've explained above, would keep the backward compatibility, with not changes required to the existing themes or plugins.

    At the same time, developers, can gradually move to the new way for handling options.

    After a while, they will be kindly asked to move to this new way, before the old way will become deprecated.
    Eventually, the new way will become the only way (*).

    Well, that's actually the normal way to introduce new features: it's nothing new and, again, I don't see, in my idea, nothing that could hurt legacy plugins or themes.

    As for cleaning options, with this approach would be quite easy to keep the _option table clean, either with a plugin or with a core feature.

    (*) After a while, what in my class is an optional constructor argument (the $context), will become mandatory (still not 100% the best solution, as developers could still put anything there, but in my opinion is still a better option than having no control at all about options).

    Or maybe, the "context" can be even automatically detected by WordPress itself (not sure how and if it's possible)./blockquote>

    Posted: 10 months ago #

RSS feed for this topic

Reply

You must log in to post.

  • Rating

    12345
    4 Votes
  • Status

    This idea is under consideration