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


10

We have to look a bit deeper here to get an answer to your question. So, bloginfo is a simple wrapper around get_bloginfo. <?php function bloginfo( $show='' ) { echo get_bloginfo( $show, 'display' ); } Notice the second argument display. Let's see what that does. <?php function get_bloginfo( $show = '', $filter = 'raw' ) { // snip snip, ...


7

I didn't find much information about how the autoloaded values are used. There is no special case for autoloaded options, they are used in the same way as else regular options, but lets figure out what autoload column of the options table means. This column determines do we need to fetch an option at the initialization stage of a request or should we ...


7

Usually I remove the filter, then add it back on afterwards; function _my_custom_option( $option ) { remove_filter( 'pre_option_name', '_my_custom_option' ); // do what you like with $option add_filter( 'pre_option_name', '_my_custom_option' ); return $option; } add_filter( 'pre_option_name', '_my_custom_option' );


6

The two functions output exactly the same thing. From the Codex entry for get_bloginfo(): 'name' - Returns the "Site Title" set in Settings > General. This data is retrieved from the "blogname" record in the wp_options table. From source: case 'name': default: $output = get_option('blogname'); Neither get_bloginfo() nor bloginfo() do any sort ...


4

Pull the add_action() outside of the function, and put the conditional inside the callback. Also, if you're printing a script directly, use wp_print_scripts instead of wp_head. You also have a syntax error. function testingone(){ if( get_option( 'MyOptionName' ) ) { ?> <script>var Script = GoesHere; </script> ...


4

Widgets can be used multiple times. Your options will be passed to the widget directly and automatically, as part of the $instance variable. You should not be getting the options directly using get_option. The widget() function declaration in a WP_Widget derived class looks like this: function widget( $args, $instance ) The $instance variable will be ...


4

No, this won't work: <?php echo get_option('notice_data[Message]'); ?> Because get_option pulls whole option value by option_name, it doesn't pull by pieces of the serialized array. What you are asking for is a key (option_name) called literally notice_data[Message]. Assuming you've saved the option as notice_data you aren't going to get a match, ...


3

Try turning your code around: function testingone() { if( FALSE !== get_option( 'MyOptionName' ) ) { echo( 'ok, this is in the head!' ); } } add_action( 'wp_head', 'testingone' ); As well, check in your theme's files (most likely header.php) to make sure that the wp_head() function is being called, and make sure that the MyOptionName ...


3

see below code.Add IF statement inside the function. function testingone(){ if(get_option( 'MyOptionName' )){ ?> <script>var Script = GoesHere; </script> <?php } } add_action('wp_head','testingone');


3

When in doubt, look at the source code. Digging in to get_option(), you'll see (abbreviated): $value = wp_cache_get( $option, 'options' ); if ( false === $value ) { $row = $wpdb->get_row( $wpdb->prepare( "SELECT option_value FROM $wpdb->options WHERE option_name = %s LIMIT 1", $option ) ); // Has to be get_row instead of get_var because ...


3

How plugins loading works WordPress has, as any other software, a specific order in which files get loaded. During loading WPs core files, there're specific points where you can either hook into do_action() or alter data during apply_filters() calls. Those functions always get called with a minimum of one argument: The name. Sometimes there're more ...


3

Turn your external file into a WordPress plugin. That way you'll have full access to WP core functions.


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

Both ways are almost equal, the first will be slightly faster, because the callback is called only if the check equals to TRUE. Note you cannot test an option like this, unless the option name is really 'my_option[option_1]'. What you probably want is: if ( $test = get_option('my_option') and 1 === $test['option_1'] ) add_action(); An extended ...


3

$mytimestamp = date(get_option('date_format'), strtotime($date)) . ' at ' . date(get_option('time_format'), strtotime($date));


3

You don't. The get_option() function is a WordPress function. You cannot use it without loading WordPress. More to the point, you should not be calling a file in your plugin directly. You should make your form or whatever is directly linking to that file link to a normal WordPress endpoint instead, and have additional parameters in your plugin to load that ...


3

The answer that yes, the theme_mod functions will be slower, but not significantly, and the benefits outweigh the differences. Theme mods are stored as options. So, in essence, the theme_mod functions are wrappers around the options functions. First, understand that theme_mod settings are stored as an array in a single option, keyed to the specific theme ...


2

If you're building something for public consumption (a plugin, a theme, etc) use admin-ajax.php like you should because that is the appropriate and accepted way to do things and gives your end users the power they need to change and modify things if they so choose. Beyond that, the best you MAY be able to do is use the SHORTINIT constant. Define it in a ...


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

Actually, there's not too much you can do. If an intruder has direct access to your site - where they can run get_option() or perform direct SQL queries - then you've already run into a problem. The safest bet here is to exercise your best judgement when installing new plugins. In other words, the best plan of action is prevention. Don't install plugins ...


2

WordPress load is complicated process and hard to grasp in full. The very basic overview would be like this. What you should do for starters - think in specifics. A lot of common tasks (adding scripts, using hooks, etc) are standardized technically or conventionally. So go by task - decide what you want to do and search (and ask if search fails you) what is ...


2

<?php $user_id = 9; $key = 'last_name'; $single = true; $user_last = get_user_meta( $user_id, $key, $single ); echo '<p>The '. $key . ' value for user id ' . $user_id . ' is: ' . $user_last . '</p>'; ?> More information here - http://codex.wordpress.org/Function_Reference/get_user_meta


2

this line: $slider_query->query("posts_per_page=5&tag=".(get_option('cgr_slider_tag'))" "); should be: $slider_query->query("posts_per_page=5&tag=".(get_option('cgr_slider_tag')));


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

Define an array of parameters to be injected into the script: $script_params = array( 'myWidth' => get_option('my_width') ); Localize the script via wp_localize_script: wp_localize_script( 'your-script-handle', 'scriptParams', $script_params ); scriptParams now is a js object you can access from within the script: alert( scriptParams.myWidth ); ...


2

The simplest way is include wp-load.php file. This file will loads all WP core, so you can use WP functions such as get_option in your PHP file: include 'path/to/wp-load.php'; echo get_option( 'option_name' );


1

The shortest way is to load wp-load.php and abort the loading of the template engine (Note: You couldn't do that, if you'd be loading the header file, like you see it on many sites in the interweb). # No need for the template engine define( 'WP_USE_THEMES', false ); # Load WordPress Core // Assuming we're in a subdir: "~/wp-content/plugins/current_dir" ...


1

You should hook your function to the WordPress AJAX Api. function your_ajax_function() { // your Script here } add_action( 'wp_ajax_your_ajax_function', 'your_ajax_function' ); add_action( 'wp_ajax_nopriv_your_ajax_function', 'your_ajax_function' ); // Skip this line if you want the AJAX just for logged in users Now you can easily call your function ...


1

Generally, you cannot access local variables in a function from outside the function, so this... function func() { $var = 2; } $var = 1; func(); echo $var; would result in "1". To make a global variable, you can do this to make $option available outside functions.php: function func() { global $option; $option = get_option( 'simple_options' ...



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