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

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

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 ...


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.


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 ...


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.


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 ...


2

Turn on Privacy or Incognito mode, or use another browser, it's the only reliable way of doing it. People may give you filters that may get rid of one thing ro another but there'll never be a 100% perfect code fix. Asking for a solution that allows you to view the frontend as if your not logged in introduces a whole new raft of issues such as people not ...


2

I found a way to do that. This is how to Consolidate Options with Arrays described in this article http://striderweb.com/nerdaphernalia/2008/07/consolidate-options-with-arrays/ Related question: How do you store options with a:n:{{}} syntax in wp_options?


2

How about putting the current section in a hidden form field inside each section, and then when you reload the page, check $_POST['section']?



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