Hot answers tagged

20

Yes, sort of. When the get_option call is made, WordPress runs a function called wp_load_alloptions, which either grabs a cached copy of all autoloaded options or loads all those options into the cache. Then wp_load_alloptions returns an array of all the autoloaded options. If your option is autoloaded (specified when you use the add_option function), it ...


11

You can use wp_add_inline_style() to add to a stylesheet that you've already defined, such as in your plugin. This way an options screen or other user settings can affect the final style output. That could become very tedious, however, depending on how many changes you are giving the user the power over. However, it is the "best practice" as far as I know.


10

There is no index because the need for it was never strong enough. In ticket #14258 it was suggested, but since most options use autoload=yes by default, the index would be ignored anyway. There is also the still open ticket #24044 _Add index to wp_options to aid/improve performance_. I think you should create an index. It will survive upgrades. It might ...


7

Update: The reason the query is being logged is it doesn't use an index. The query time is 0, i.e. it actually executes fast. You can unset the "log-queries-not-using-indexes" option if you don't want these to be logged. The wp_options table has no index on autoload, so the query ends up doing a full table scan. In general that table shouldn't get too ...


7

Ajax in WordPress works by sending an HTTP post to /wp-admin/admin-ajax.php (by default) that then fires the corresponding hook. So, you attach some jquery to an event triggered by your delete button, which then posts to admin-ajax.php, which has an action, say, delete_my_options(), which actually runs the php to delete. Then, you have a function, called a ...


6

It depends on how you are going to use the stored data. If you want to run complex queries against the values, use a custom table with indexes optimized for those queries. If you will always just fetch all the values for a given object, create a non-public custom post type, and store the data as post meta. Do not store the data in a serialized string, ...


4

Yep, this does seem like a cron issue. Core Control plugin is good to diagnose cron tasks (among other things). I am still unsure what is the reason of you getting overrun with feed transients. However I had written some code that might help with automatic cleanup.


4

It makes sense that if it's faster to use a new table for a thousand entries, it must also be faster for tens or hundreds of entries. Performance is not about the pure number rows – the real amount of data and their structure counts. Usually, you use just the theme mod API. Your theme data is on a predictable place and can easily exported or changed by ...


4

Assuming this array for example usage: $options = array( "name" => __('Font','mytheme'), "desc" => __('Change the font face)','mytheme'), "id" => "mytheme_font", "std" => array('size' => '10px', 'face' => 'Arial', 'color' => '#000000'), "type" => "text", ); For question 1, to reference nested arrays, just ...


4

This is not an amount that is likely to cause performance issues. However if you are concerned about leftover transients it is worth looking into if any code you are using is consistently "leaking" them (creating transients that are never removed). See Are transients garbage collected? for relevant discussion and some code snippets.


4

Where to store plugin settings fields? Options table FTW. It's cached and easy to do CRUD. Settings API or Options API? Basically, you can use Options API without Settings API but you cannot use Settings API without Options API. Even when you just need to add some fields to a existing WordPress page, you still need get_option() to retrieve data for ...


3

I used: DELETE FROM `wp_options` WHERE `option_name` LIKE ('%\_transient\_%'); to cleanup with great results :) (from here http://stackoverflow.com/questions/10422574/can-i-remove-transients-in-the-wp-options-table-of-my-wordpress-install)


3

This is a fairly definitive set of responses about transients WPSE: Are transients garbage collected?


3

Those edit links are Theme-dependent, via the edit_post_link() template tag. However, there are several other, similar variances in site appearance between logged-in and non-logged-in users: the presence of the Admin bar, edit-post links, edit-comment links, login/logout/register links (added directly to the template, or via Widget), etc. These don't really ...


3

No, only the options that are specifically loaded with autoload set to true See http://codex.wordpress.org/Function_Reference/add_option So if it is an option that is needed on every page, when you add it to the db, set autoload=true. After that, just use get_option normally - wp will handle the cacheing etc.


3

If your theme framework has so many options that you're contemplating putting them in a separate table, you're Doing It Wrong™. What are the differences in query execution time, memory usage, and other factors between these two options? It depends on how you build the table (column data types, indexes), how many rows it has and what kind of queries you'...


3

creating a custom script that writes to the static CSS file is a bad idea!!! you would need to regenerate the file each time you save any changes. a better solution would be to save all options in an array of options say for example: $MyCSS['background_color'] = #009988; $MyCSS['background_repeat'] = no-repeat; update_option('theme_settings',$MyCSS); and ...


3

The entries life for different time. You can run a sql for delete all: DELETE FROMwp_optionsWHEREoption_nameLIKE ('_transient%_feed_%') THe easiest wy for run a sql direct on the database is the plugin Adminer inside the WP Backend. More you can read on this post about delete the transient-cache of feeds.


3

The process of saving option conveniently offers filter for new value, with access to old value as well. We only need to combine both and give it to WP as value to save: add_filter( 'pre_update_option_recently_edited', 'increase_recently_edited_list', 10, 2 ); function increase_recently_edited_list( $newvalue, $oldvalue ) { return array_slice( ...


3

I stumbled across the query mentioned in mytop running on my server a few days ago - and it actually took quite some time (about 10 seconds) for each query! So there are real-world situations where wp_options might grow to problematic size. In my case I suspect the caching plugin Cachify to be responsible for bloating wp_options. Data of this particular ...


3

The ability to store abstract key-value pairs without modifying the database structure is the reason. Without that, WordPress loses much of its flexibility. I can't speak for others, but the single largest reason why I develop atop WordPress is its flexible nature. To quote one of your links above, Usually the reasoning behind doing what you are doing ...


3

The framework offers a filter for validating input values inside the optionsframework_validate function. Just for reference, here's the relevant part from the file wp-content/themes/your-theme/inc/options-framework.php: /** * Validate Options. * * This runs after the submit/reset button has been clicked and * validates the inputs. */ function ...


3

The option you're showing in your question is a serialized array. Retrieving the option with get_option() gives you back the array, but unserialized. This is done by maybe_unserialize(), which get_option uses. Just add a new 'key' => 'value' pair to the array you retrieved and then update the option with update_option(), et voilà you have added the ...


3

You can use following: update_option( 'show_on_front', 'page' ); update_option( 'page_on_front', '0' ); I hope this helps.


3

This is actually not that hard, but you will have to excuse me for keeping it high level because this is just a stupid thing to do as all things which are security by obscurity. All you need to do is write your WPDB driver, which inherits the WPDB class. Place it in /wp-content/db.php file and make sure to initialize the global $wpdb object with your class. ...


2

See the filter reference on the codex. In particular, note that you can use the form option_$foo to filter just a specific option key. So if you wanted a filter specific to the siteurl option, you could do: add_filter( 'option_siteurl', 'my_url_filter' );


2

The following should do it: function get_hidden_cats() { $my_cats = get_option('ce4_category_fields'); $my_hidden_cats = array(); foreach( $my_cats as $cat_id => $cat_attrs ) { if( 'true' == $cat_attrs['my_cat_hide'] ) $my_hidden_cats[] = $cat_id; } $my_hidden_cats = implode( ',', $my_hidden_cats ); return $...


2

Try esc_html( $string ) (Codex ref), which among other things encodes single- and double-quotes. For further reference, see the Data Validation entry in the Codex.


2

Rather than modifying stored rules it would be more reliable to modify rules before they are stored. flush_rewrite_rules() calls WP_Rewrite->flush_rules() WP_Rewrite->wp_rewrite_rules() WP_Rewrite->rewrite_rules() Inside last there are fitting hooks to modify rules (after which result they will be saved as usual on each flush): ...


2

If you are using the Settings API then you don't have to save the options, that's done for you. So when using an array to store the options your validation function should get an array of all existing options, update only the changed and return that array. Something like this: function my_settings_option_validate( $input ) { //do regular validation ...



Only top voted, non community-wiki answers of a minimum length are eligible