Tag Info

Hot answers tagged

16

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


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

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


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

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

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

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

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


2

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


2

I presume your options are being saved in an array under a single key and not actually within the native options WP uses. You can add an action to update_option_{$option_name} to update the options famework entry when an option is updated outside your own options panel. You'll have to figure out what key your own options are being saved under.


2

Of course it is not a good practice, since it will be considered as plugin error by Wordpress. It will output an error message on plugin activation like this: The plugin generated xxx characters of unexpected output during activation. If you notice “headers already sent” messages, problems with syndication feeds or other issues, try deactivating or removing ...


2

If you just want to get rid of the \ characters in the string that's returned, you can use PHP's stripslashes(): $content = stripslashes( $content ); I'd recommend doing this on output rather than on input; WordPress adds the slashes as it sanitizes your data on insert, per update_option()'s Codex page, The $option (option name) value is escaped with ...


2

I'm running 3 WP blogs on a Debian Squeeze large instance and was investigating why mysql was stuck on that host at 200% CPU usage and system load between 3 and 6. Looking at a 'show process list' inside mysql, we understood the wp_option table was involved in this issue so we executed: alter table wp_options add index autoload_idx(`autoload`); After ...


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

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

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


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']?


2

There is a plugin called - Clean Options which promises to remove all unused entries from wp_options table. NOTE - that plugin hasn't been updated for 2 years, you must do backup before using it. To remove all data manually You have to manually look into database for unused tables or rows and use the SQL query to delete those permanently from the database. ...


2

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


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

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.


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.


1

WordPress uses maybe_serialize() and maybe_unserialize(). Both of them use PHP's native serialize() and unserialize() functions. See: http://phpxref.ftwr.co.uk/wordpress/wp-includes/functions.php.source.html#l1028 http://phpxref.ftwr.co.uk/wordpress/wp-includes/functions.php.source.html#l222 Both of those functions make use of the function ...



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