Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

I have users when get an 'Invalid Error' when trying to edit the custom theme options in my theme, WPFolio. The options (just some CSS rules: page container color, font color, headline/body font, etc...) work as they should in Firefox, Safari, and IE and any changes they make there will show up in Chrome fine. But when they try to edit/save theme options in Chrome, they get an 'Invalid Value' error on a specific field when they try to save in Chrome, even if they haven't touched that field.

The weird thing is, I can't replicate the error no matter what browser I use...

Any ideas? Thanks!

Have a look at the theme files on github.

share|improve this question
    
"specific field" is what exact field? –  kaiser Mar 16 '11 at 20:31
    
well, of course, I can't replicate it. But from what's been reported to me, the error happens whether you've changed the field or not. –  SteveLambert Mar 17 '11 at 2:02
add comment

1 Answer

Ehm, yea. I don't know what exactly your problem is, so some notes about the code below.

You should use the settings API. Here's a (new) tutorial by Chip Bennet. The way you're calling your currently set options (one get_option call per sub-array) you have about 11 db-calls only for your options. If you don't think about switching to the settings API, you should anyway only call get_option once, save it into some variable like $current_options = get_options('whatever'); and then go through it with $current_options['some_sub_arr'];.

I try to not be harsh, so please don't get this in the wrong throught: The file is close to unreadable (for me). So many unnecassary tabs and line breaks. I hoped i could help, but i can't really help you with your specific problem.

Maybe it helps: There's a lot of other stuff i can say about this theme. I hope you can take some (positive) criticism (that helps making it better).

  • As long as you don't want to use a $var inside a string you don't have to use double quotes Example:
    array( "key" => "value" ) could be written as array( 'key' => 'value' ) and will be much faster (meassured up to 5x faster).
  • When using numerical index arrays, then you don't have to write array( '0' => 'value' ) it's a numerical array per default if you don't specify a key.
  • Never ever - really: never ever - use names for variables like $options when outside a class. Those will populate the global namespace and somewhen (surely) conflict with some other stuff

To handle names centrally (and not spread across all files like $options):

 $wpfolio_options_default = array ( '...' => '...' );

    define ( 'WPFOLIO_OPTS', 'wpfolio_options_theme' );

// your global $var for theme users - do this only when you're really sure that nothing will change in there. Ever.
$wpfolio_options = get_option( WPFOLIO_OPTS );

    function template_tag_whatever() 
    {
       // If you're in the need to change the name of the options field in the DB, change it above in the define call
       $all_options = get_option( WPFOLIO_OPTS );   
       // if you've made your options globaly available (if the behavior might change - themes may break, so do this with caution)
       // global $wpfolio_options
       // $background = $wpfolio_options['background_class'];
       $background = $all_options['background_class'];
        ?>
        <div class="<?php echo $background; ?>">
         <!-- some stuff -->
        </div>
        <?php
    }

// inside a template:
global $wpfolio_options;
if ( isset($wpfolio_options['portfolio_category']) )
{
echo $wpfolio_options['portfolio_category'];
}

But: It's still better - and much easier - to deal with the settings API. The above example was only mentioned to show you how much easier it is to handle names through Constants (see STYLESHEETPATH, etc.).

share|improve this answer
    
Kaiser, I will look into all this. I really appreciate your notes! We work on this as a collaborative project - all volunteers. So we don't always catch everything. Also, we're trying to make it backwards compatible with an earlier version which gets a little weird. But your notes are helpful and we will look into it. –  SteveLambert Mar 17 '11 at 2:04
    
@SteveLambert: Glad you didnt get it wrong at all :) ... Staying backwards compatible is something for Joomla or Drupal and such CMS systems. The wp core itself isn't backwards compatible and will even drop support for everything below php 5.2 with the next version (coming in less than 4 month). –  kaiser Mar 17 '11 at 2:56
    
@SteveLambert: See updated A. –  kaiser Mar 17 '11 at 3:17
    
I think Steve was referring to backwards compatibility with an older version of the theme, ie. providing a means for users running older copies to upgrade and import older options into the newer verion(eg. the code checks for the existance of old options and converts them into the new array'ed format). NOTE: Steve's code is actually using a single arrayed option to store all the data(not several like you stated in your answer). If there's anything that needs pointing out, it's the lack of any sanitization inside the registered setting callback function. –  t31os Mar 17 '11 at 11:06
    
@t31os: Older Versions of the theme explain a lot to me. And btw: i didn't say he isn't using a single array. I said, he has 11 queries (one get_option call for each sub-array). So i modified my answer to show him how to avoid the calls with storing the whole array into the global $wpfolio_options or retrieving and modifiying sub-arrays with $all_options = get_option( WPFOLIO_OPTS ); at the function. Everything only examples above. But you're absolutely right in the point, that sanitization is missing. –  kaiser Mar 17 '11 at 15:42
show 4 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.