So, when I originally forked this from SMOF and NHP I thought to make this SMOF on steroids. This has actually progressed far beyond SMOF in a lot of ways. So, since I'm doing things over I want to do them right.

So I am curious if this would cause lots of issues for people:

To date SMOF declares a field like thus:

$of_options[] = array(  
    "name"      => "Home Settings",
    "type"      => "heading"
);

$of_options[] = array(
    "name"      => "Media Uploader 3.5",
    "desc"      => "Upload images using native media uploader from Wordpress 3.5+.",
    "id"        => "media_upload_35",
    "std"       => "",
    "type"      => "upload"
);

Right now, SOF declares it like this. Note I've mapped the type of upload to the SOF version of media so SMOF declarations can be used for all but sections.

$sections[] = array(
    "icon"      => "",
    "title"     => __("Home Settings", "simple-options"),
    "header"    => __("Welcome to the Simple Options Framework Demo", "simple-options"),
    "desc"      => __("Simple Options Framework was created with the developer in mind. It allows for any theme developer to have an advanced theme panel with most of the features a developer would need. For more information check out the Github repo at: <a href="http://github.com/SimpleRain/SimpleOptions/">http://github.com/SimpleRain/SimpleOptions/</a>", "simple-options"),
    "icon"      => SOF_OPTIONS_URL."img/glyphicons/glyphicons_020_home.png",
    "fields"    => array(
            "id"            => "media", //must be unique
            "type"          => "media", 
            "title"         => __("Media", "simple-options"),
            "sub_desc"  => __("Upload any media using the Wordpress native uploader", "simple-options"),
            ),
);

However, I wonder if this convention is bad. I know it's been the standard for a while, but I want to mirror Wordpress more closely. Notice the $wp_customize api as outlined here: http://ottopress.com/2012/how-to-leverage-the-theme-customizer-in-your-own-themes/

Look at how a section is defined, namely:

$wp_customize->add_section( "themename_color_scheme", array(
  "title"     => __( "Color Scheme", "themename" ),
  "priority"  => 35,
) );

Then look at a field, or how a "control" is defined:

$wp_customize->add_control( "themename_color_scheme", array(
  "label"      => __( "Color Scheme", "themename" ),
  "section"    => "themename_color_scheme",
  "settings"   => "themename_theme_options[color_scheme]",
  "type"       => "radio",
  "choices"    => array(
    "value1" => "Choice 1",
    "value2" => "Choice 2",
    "value3" => "Choice 3",
    ),
) );

So I thought, why not just do the same for SOF and change some of the labels to match Wordpress. So for example:

$Simple_Options->add_section("home_settings", array(
    "label"         => __("Home Settings", "simple-options"),
    "icon"              => "",
    "priority"    => 10,
    "description" => __("Simple Options Framework was created with the developer in mind. It allows for any theme developer to have an advanced theme panel with most of the features a developer would need. For more information check out the Github repo at: <a href="http://github.com/SimpleRain/SimpleOptions/">http://github.com/SimpleRain/SimpleOptions/</a>", "simple-options"),
));

And for a field:

$Simple_Options->add_field("ID", array(
    "label"         => __("Home Settings", "simple-options"),
    "section"       => "home_settings",
    "type"              => "media",
    "sub"               => __("This is a media item", "simple-options"),
    "priority"      => 10,
    "description" => __("This is a description of the media item", "simple-options"),
))

We'd then of course allow for add_fields, and add_sections for mass adding (arrays).

I want to follow convention as much as possible, but would this detract from people being willing to use the framework? Is following Wordpress" methodologies too much of a shift?

Would you still use SOF or would this keep you from using it?

@dhechler @Smartik89 @teamcrisis @aristath @azharijelek @krishna19 @pe6o @tyl3r @syamilmj

@dovy, I would lean toward "the wordpress way" but then again, I have a lot of time invested in SMOF. So, as long as the transition is relatively straightforward and doesn't require me to rewrite my entire base theme, I'd be okay with the shift.

I think it'd be great. Progressing forward is never bad

—

Sent from Mailbox for iPhone

On Wed, Aug 21, 2013 at 4:44 PM, Dovy Paukstys notifications@github.com wrote:

So, when I originally forked this from SMOF and NHP I thought to make this SMOF on steroids. This has actually progressed far beyond SMOF in a lot of ways. So, since I'm doing things over I want to do them right. So I am curious if this would cause lots of issues for people: To date SMOF declares a field like thus:
$of_options[] = array(    
  "name"      => "Home Settings",
  "type"      => "heading"
);
$of_options[] = array(
  "name"      => "Media Uploader 3.5",
  "desc"      => "Upload images using native media uploader from Wordpress 3.5+.",
  "id"        => "media_upload_35",
  "std"       => "",
  "type"      => "upload"
);
Right now, SOF declares it like this. Note I've mapped the type of upload to the SOF version of media so SMOF declarations can be used for all but sections.
$sections[] = array(
  "icon"      => "",
  "title"     => __("Home Settings", "simple-options"),
  "header"    => __("Welcome to the Simple Options Framework Demo", "simple-options"),
  "desc"      => __("Simple Options Framework was created with the developer in mind. It allows for any theme developer to have an advanced theme panel with most of the features a developer would need. For more information check out the Github repo at: <a href="http://github.com/SimpleRain/SimpleOptions/">http://github.com/SimpleRain/SimpleOptions/</a>", "simple-options"),
  "icon"      => SOF_OPTIONS_URL."img/glyphicons/glyphicons_020_home.png",
  "fields"    => array(
          "id"            => "media", //must be unique
          "type"          => "media", 
          "title"         => __("Media", "simple-options"),
          "sub_desc"  => __("Upload any media using the Wordpress native uploader", "simple-options"),
          ),
);
However, I wonder if this convention is bad. I know it's been the standard for a while, but I want to mirror Wordpress more closely. Notice the $wp_customize api as outlined here: http://ottopress.com/2012/how-to-leverage-the-theme-customizer-in-your-own-themes/ Look at how a section is defined, namely:
$wp_customize->add_section( "themename_color_scheme", array(
  "title"     => __( "Color Scheme", "themename" ),
  "priority"  => 35,
) );
Then look at a field, or how a "control" is defined:
$wp_customize->add_control( "themename_color_scheme", array(
  "label"      => __( "Color Scheme", "themename" ),
  "section"    => "themename_color_scheme",
  "settings"   => "themename_theme_options[color_scheme]",
  "type"       => "radio",
  "choices"    => array(
    "value1" => "Choice 1",
    "value2" => "Choice 2",
    "value3" => "Choice 3",
    ),
) );
So I thought, why not just do the same for SOF and change some of the labels to match Wordpress. So for example:
$Simple_Options->add_section("home_settings", array(
    "label"           => __("Home Settings", "simple-options"),
    "icon"                => "",
    "priority"    => 10,
    "description" => __("Simple Options Framework was created with the developer in mind. It allows for any theme developer to have an advanced theme panel with most of the features a developer would need. For more information check out the Github repo at: <a href="http://github.com/SimpleRain/SimpleOptions/">http://github.com/SimpleRain/SimpleOptions/</a>", "simple-options"),
));
And for a field:
$Simple_Options->add_field("ID", array(
    "label"           => __("Home Settings", "simple-options"),
    "section"         => "home_settings",
    "type"                => "media",
    "sub"                 => __("This is a media item", "simple-options"),
    "priority"    => 10,
    "description" => __("This is a description of the media item", "simple-options"),
))
We'd then of course allow for add_fields, and add_sections for mass adding (arrays). I want to follow convention as much as possible, but would this detract from people being willing to use the framework? Is following Wordpress" methodologies too much of a shift? Would you still use SOF or would this keep you from using it?

@dhechler @Smartik89 @teamcrisis @aristath @azharijelek @krishna19 @pe6o @tyl3r @syamilmj

Reply to this email directly or view it on GitHub: https://github.com/SimpleRain/SimpleOptions/issues/23

I don't know why this should be a problem for me. It looks ok and more organized. I'm for this:

$sections[] = array(
    "icon"      => "",
    "title"     => __("Home Settings", "simple-options"),
    "header"    => __("Welcome to the Simple Options Framework Demo", "simple-options"),
    "desc"      => __("Simple Options Framework was created with the developer in mind. It allows for any theme developer to have an advanced theme panel with most of the features a developer would need. For more information check out the Github repo at: <a href="http://github.com/SimpleRain/SimpleOptions/">http://github.com/SimpleRain/SimpleOptions/</a>", "simple-options"),
    "icon"      => SOF_OPTIONS_URL."img/glyphicons/glyphicons_020_home.png",
    "fields"    => array(
            "id"            => "media", //must be unique
            "type"          => "media", 
            "title"         => __("Media", "simple-options"),
            "sub_desc"  => __("Upload any media using the Wordpress native uploader", "simple-options"),
            ),
);

The way how WP_Customize declare fields looks bad from my point of view.

Yeah, I'm also for the way Smartik89 said. It just looks more organized.

SMOF and the Options framework are both pretty famous and widely used. However, they both make some assumptions and use a syntax different to the one used by WordPress core.

They were both built way before the introduction of the Customizer, and their syntax is different to what is now part of the WordPress core. The Customizer is here to stay and a lot of themes define their fields in there for simplicity's sake. What's more, a whole generation of WP devs will learn how to use the customizer to enhance themes.

SMOF was nice for a while, but we all see its limitations and flaws on a daily basis. SimpleOption was created because SMOF and other similar frameworks had their limitations and we're trying to be better than that! IMHO we should not be concerned about compatibility with other frameworks, or how easy the migration will be from one to the other. We should be focusing on how to make this the best that we can do. The best that we can do is not extend and improve SMOF and similar frameworks, but extend and improve WordPress core!

If we make this SMOF-compatible, then it will be easier for existing themes to switch to this. But I don't think that anyone can disagree with me when I say that in the long run it's better if we make this different and more core-like.

Anyway, just my 2 cents...

@aristath , if you did't know, WP customizer can be extended to allow you to define all fields just like in SMOF. Nothing hard, is just the preference.

@smartik89 Yeah, I know. The point is that fields are defined using a slightly different syntax. This issue is about what path we want this framework to follow... Smof - like syntax, or customizer - like syntax? I vote for customizer - like.

@aristath, if Wordpress choice is to define them so, then it's ok for Customizer, but that doesn't mean they do it right. Wordpress itself isn't a well coded platform. Just what I want to say is that everytime we try to extend wordpress we make the code simpler and easy to re-use again and again.

I'm sure that creating all fields from a multidimensional array is better than calling a PHP class everytime, and the code is readable.

If is to say something about WP Customizer, I always forget to add the section and priority to each field. I don't know who the hell need this, isn't it easier to parse the code as it is, how I wrote it, in which order I wrote it?

@Smartik89 yeah, but my scenario is a bit different: I'm not building a theme but an extensible and modular framework. My use case requires defining a section for each field. If it's there then you don't lose anything (except the 5 minutes it will take you to write a couple more lines) and all use cases can be implemented, even mine! If it's not there, then you get to write a couple less lines of code and I can't use it on my project.

We all chose to work with WordPress, whether we like or not the way it's written we made that choice and we should make it easier for others to write their code using stuff they already know, without having to read a whole different documentation for something that should be simple. If they know how to add fields and sections in the customizer then they will simply be able to copy-paste that and simply change a class name!!

Extensibility and modularity sometimes require writing a couple more lines. It's not a bad thing... The fact that you don't need it now doesn't mean that you won't need it in the future.

I don't think the WP Customizer way of handling things is bad at all. It's very structured and easy to understand. Just because you forget to add section and priority to your options doesn't mean it doesn't work well. That's just you forgetting.

David Hechler

On Thursday, August 22, 2013 at 2:04 PM, Andrei Surdu wrote:

@aristath (https://github.com/aristath), if Wordpress choice is to define them so, then it's ok for Customizer, but that doesn't mean they do it right. Wordpress itself isn't a well coded platform. Just what I want to say is that everytime we try to extend wordpress we make the code simpler and easy to re-use again and again. I'm sure that creating all fields from a multidimensional array is better than calling a PHP class everytime, and the code is readable. If is to say something about WP Customizer, I always forget to add the section and priority to each field. I don't know who the hell need this, isn't it easier to parse the code as it is, how I wrote it, in which order I wrote it?

— Reply to this email directly or view it on GitHub (https://github.com/SimpleRain/SimpleOptions/issues/23#issuecomment-23116603).

@aristath @Smartik89 @dhechler @pe6o

So let me say I'm mindful of both. I want the standard method to be understood and new methods to be used as well. I'm doing my best to bridge both worlds. So, here's another proposal. You can see it (and read it better) here:

$Simple_Options->add_section()

$Simple_Options->add_section("ID", array(
    "label" => __( "Section Label", "simple-options" ), // Title/label. Same diff.
    "heading" => __( "Section Heading", "simple-options" ), // Heading text that appears in the right panel if wanted to be different from the menu
    "description" => __( "Section Description", "simple-options" ), // If not defined, it will be taken from the title
    "priority" => 1, // If not defined it will be psudo generated for you. Only applies for customizer really. Changes the order of appearance.
    "icon" => "URL"
))

$Simple_Options->add_field()

$Simple_Options->add_field("ID", array(
    "label" => __( "Section Label", "simple-options" ), // Title/label. Same diff.
    "subtitle" => "STRING", // Text that appears on the left under the label
    "description" => "STRING", // Text that appears below the field on the right
    "priority" => 1, // If not defined it will be psudo generated for you. Only applies for customizer.
    "type" => "STRING", // Field type
    "options" => array("OPTIONS")/STRING, // String or Array of options
    "data" => "STRING" // Used by a few items that have the data pulled from wordpress
    "customizer" => false // If customizer is enabled, this will disable it for this field
))

If you want the class to do it for you then use:

$Simple_Options->add_fields()

Uses the same array as above, just you can do it all at once.

$Simple_Options->add_fields(array(
    "ID"=>array(
        "section" => "SECTION_ID", // ID of your section. If not defined, it will be created for you and display as such
        "label" => __( "Section Label", "simple-options" ), // Title/label. Same diff.
        "subtitle" => "STRING", // Text that appears on the left under the label
        "description" => "STRING", // Text that appears below the field on the right
        "priority" => 1, // If not defined it will be psudo generated for you. Only applies for customizer.
        "type" => "STRING", // Field type
        "options" => array("OPTIONS")/STRING, // String or Array of options
        "data" => "STRING" // Used by a few items that have the data pulled from wordpress
        "customizer" => false // If customizer is enabled, this will disable it for this field
    ),
    "ID2"=>array(
        "section" => "SECTION_ID", // ID of your section. If not defined, it will be created for you and display as such    
        "label" => __( "Section Label", "simple-options" ), // Title/label. Same diff.
        "subtitle" => "STRING", // Text that appears on the left under the label
        "description" => "STRING", // Text that appears below the field on the right
        "priority" => 1, // If not defined it will be psudo generated for you. Only applies for customizer.
        "type" => "STRING", // Field type
        "options" => array("OPTIONS")/STRING, // String or Array of options
        "data" => "STRING" // Used by a few items that have the data pulled from wordpress
        "customizer" => false // If customizer is enabled, this will disable it for this field
    )
));

$Simple_Options->add_sections()

Uses the same array as above, just you can do it all at once.

$Simple_Options->add_sections(array(
    "sectionID"=>array(
        "label" => __( "Section Label", "simple-options" ), // Title/label. Same diff.
        "heading" => __( "Section Heading", "simple-options" ), // Heading text that appears in the right panel if wanted to be different from the menu
        "description" => __( "Section Description", "simple-options" ), // If not defined, it will be taken from the title
        "priority" => 1, // If not defined it will be psudo generated for you. Only applies for customizer really. Changes the order of appearance.
        "icon" => "URL"
    ),
    "ID2"=>array(
        "label" => __( "Section Label", "simple-options" ), // Title/label. Same diff.
        "heading" => __( "Section Heading", "simple-options" ), // Heading text that appears in the right panel if wanted to be different from the menu
        "description" => __( "Section Description", "simple-options" ), // If not defined, it will be taken from the title
        "priority" => 1, // If not defined it will be psudo generated for you. Only applies for customizer really. Changes the order of appearance.
        "icon" => "URL"
    ),
));

Now what about...

We COULD potentially allow you to spool the same with but with fields for sections. As in:

$Simple_Options->add_sections( array(
    "sectionID"=>array(
        "label" => __( "Section Label", "simple-options" ), // Title/label. Same diff.
        "heading" => __( "Section Heading", "simple-options" ), // Heading text that appears in the right panel if wanted to be different from the menu
        "description" => __( "Section Description", "simple-options" ), // If not defined, it will be taken from the title
        "priority" => 1, // If not defined it will be psudo generated for you. Only applies for customizer really. Changes the order of appearance.
        "icon" => "URL",
        fields => array(
            "ID"=>array(
                "label" => __( "Section Label", "simple-options" ), // Title/label. Same diff.
                "subtitle" => "STRING", // Text that appears on the left under the label
                "description" => "STRING", // Text that appears below the field on the right
                "priority" => 1, // If not defined it will be psudo generated for you. Only applies for customizer.
                "type" => "STRING", // Field type
                "options" => array("OPTIONS")/STRING, // String or Array of options
                "data" => "STRING" // Used by a few items that have the data pulled from wordpress
                "customizer" => false // If customizer is enabled, this will disable it for this field
            ),
            "ID2"=>array(
                "label" => __( "Section Label", "simple-options" ), // Title/label. Same diff.
                "subtitle" => "STRING", // Text that appears on the left under the label
                "description" => "STRING", // Text that appears below the field on the right
                "priority" => 1, // If not defined it will be psudo generated for you. Only applies for customizer.
                "type" => "STRING", // Field type
                "options" => array("OPTIONS")/STRING, // String or Array of options
                "data" => "STRING" // Used by a few items that have the data pulled from wordpress
                "customizer" => false // If customizer is enabled, this will disable it for this field
            )
        )
    )
));

Wherein section id's wouldn't need to be identified as we could create them on the fly.

Unfortunately this causes me a bit more work, but I think it may be the only way we can agree with everything.

Thoughts?

The only real difference between what's going on now and this is you'd have to decide a section id, as it would be needed. That's the only change. From the backend side, this has ALL KINDS of benefits. Such as quick access to any value via key rather than loop, etc.

When I modified SMOF i ended up using loops like mad to create a $SMOF_DETAILS array which was just the standard values organised by key. Painful.

I like it! Seems like a good "marriage"...

@teamcrisis @dhechler @Smartik89 @pe6o @aristath So I took a step back. This is all I am going to change...

Everything is going to stay identical to SMOF minus this one item:

<?
$sections[] = array(
                'icon' => SOF_OPTIONS_URL.'img/glyphicons/glyphicons_157_show_lines.png',
                'title' => __('Select Fields', 'simple-options'),
                'desc' => __('<p class="description">This is the Description. Again HTML is allowed</p>', 'simple-options'),
                'fields' => array(
                    "select"=>array( //must be unique
                        'type' => 'select',
                        'title' => __('Select Option', 'simple-options'), 
                        'sub_desc' => __('No validation can be done on this field type', 'simple-options'),
                        'desc' => __('This is the description field, again good for additional info.', 'simple-options'),
                        'options' => array('1' => 'Opt 1','2' => 'Opt 2','3' => 'Opt 3'),//Must provide key => value pairs for select options
                        'std' => '2'
                        ),
);

You have to define the field ID outside of the array.

Not bad eigh? We're scratching the rest and keeping it as it is. Thought you'd all like to know.

Also we're nearly to a 1.0.0 release. Please play with it and give me bugs if you find them!

Hi,

I'm krishna(Github Username: Krishna19). i already contact you using Github Issues page. But the problem is not solved. I have a problem in using SOF. I try to install as a plugin it was not working. it shows error.

I Install in Localhost(Xampp) and using Wordpress 3.6.

Thanks

On Fri, Aug 23, 2013 at 2:19 AM, Dovy Paukstys notifications@github.comwrote:

@aristath https://github.com/aristath @Smartik89https://github.com/Smartik89 @dhechler https://github.com/dhechler @pe6o https://github.com/pe6o

So let me say I'm mindful of both. I want the standard method to be understood and new methods to be used as well. I'm doing my best to bridge both worlds. So, here's another proposal. You can see it (and read it better) herehttps://github.com/SimpleRain/SimpleOptions/wiki/Proposed-Init-Functions:

$Simple_Options->add_section()

Now this slightly breaks away from the Wordpress Customizer convention. The title is defined rather than the ID.

$Simple_Options->add_section("ID", array( "label" => ( "Section Label", "simple-options" ), // Title/label. Same diff. "heading" => ( "Section Heading", "simple-options" ), // Heading text that appears in the right panel if wanted to be different from the menu "description" => __( "Section Description", "simple-options" ), // If not defined, it will be taken from the title "priority" => 1, // If not defined it will be psudo generated for you. Only applies for customizer really. Changes the order of appearance. "icon" => "URL" ))

$Simple_Options->add_field()

$Simple_Options->add_field("ID", array( "label" => __( "Section Label", "simple-options" ), // Title/label. Same diff. "subtitle" => "STRING", // Text that appears on the left under the label "description" => "STRING", // Text that appears below the field on the right "priority" => 1, // If not defined it will be psudo generated for you. Only applies for customizer. "type" => "STRING", // Field type "options" => array("OPTIONS")/STRING, // String or Array of options "data" => "STRING" // Used by a few items that have the data pulled from wordpress "customizer" => false // If customizer is enabled, this will disable it for this field ))

If you want the class to do it for you then use:

$Simple_Options->add_fields()

Uses the same array as above, just you can do it all at once.

$Simple_Options->add_fields(array( "ID"=>array( "section" => "SECTION_ID", // ID of your section. If not defined, it will be created for you and display as such "label" => __( "Section Label", "simple-options" ), // Title/label. Same diff. "subtitle" => "STRING", // Text that appears on the left under the label "description" => "STRING", // Text that appears below the field on the right "priority" => 1, // If not defined it will be psudo generated for you. Only applies for customizer. "type" => "STRING", // Field type "options" => array("OPTIONS")/STRING, // String or Array of options "data" => "STRING" // Used by a few items that have the data pulled from wordpress "customizer" => false // If customizer is enabled, this will disable it for this field ), "ID2"=>array( "section" => "SECTION_ID", // ID of your section. If not defined, it will be created for you and display as such "label" => __( "Section Label", "simple-options" ), // Title/label. Same diff. "subtitle" => "STRING", // Text that appears on the left under the label "description" => "STRING", // Text that appears below the field on the right "priority" => 1, // If not defined it will be psudo generated for you. Only applies for customizer. "type" => "STRING", // Field type "options" => array("OPTIONS")/STRING, // String or Array of options "data" => "STRING" // Used by a few items that have the data pulled from wordpress "customizer" => false // If customizer is enabled, this will disable it for this field ) ));

$Simple_Options->add_sections()

Uses the same array as above, just you can do it all at once.

$Simple_Options->add_sections(array( "sectionID"=>array( "label" => ( "Section Label", "simple-options" ), // Title/label. Same diff. "heading" => ( "Section Heading", "simple-options" ), // Heading text that appears in the right panel if wanted to be different from the menu "description" => ( "Section Description", "simple-options" ), // If not defined, it will be taken from the title "priority" => 1, // If not defined it will be psudo generated for you. Only applies for customizer really. Changes the order of appearance. "icon" => "URL" ), "ID2"=>array( "label" => ( "Section Label", "simple-options" ), // Title/label. Same diff. "heading" => ( "Section Heading", "simple-options" ), // Heading text that appears in the right panel if wanted to be different from the menu "description" => ( "Section Description", "simple-options" ), // If not defined, it will be taken from the title "priority" => 1, // If not defined it will be psudo generated for you. Only applies for customizer really. Changes the order of appearance. "icon" => "URL" ), ));

Now what about...

We COULD potentially allow you to spool the same with but with fields for sections. As in:

$Simple_Options->add_sections( array( "sectionID"=>array( "label" => ( "Section Label", "simple-options" ), // Title/label. Same diff. "heading" => ( "Section Heading", "simple-options" ), // Heading text that appears in the right panel if wanted to be different from the menu "description" => ( "Section Description", "simple-options" ), // If not defined, it will be taken from the title "priority" => 1, // If not defined it will be psudo generated for you. Only applies for customizer really. Changes the order of appearance. "icon" => "URL", fields => array( "ID"=>array( "label" => ( "Section Label", "simple-options" ), // Title/label. Same diff. "subtitle" => "STRING", // Text that appears on the left under the label "description" => "STRING", // Text that appears below the field on the right "priority" => 1, // If not defined it will be psudo generated for you. Only applies for customizer. "type" => "STRING", // Field type "options" => array("OPTIONS")/STRING, // String or Array of options "data" => "STRING" // Used by a few items that have the data pulled from wordpress "customizer" => false // If customizer is enabled, this will disable it for this field ), "ID2"=>array( "label" => __( "Section Label", "simple-options" ), // Title/label. Same diff. "subtitle" => "STRING", // Text that appears on the left under the label "description" => "STRING", // Text that appears below the field on the right "priority" => 1, // If not defined it will be psudo generated for you. Only applies for customizer. "type" => "STRING", // Field type "options" => array("OPTIONS")/STRING, // String or Array of options "data" => "STRING" // Used by a few items that have the data pulled from wordpress "customizer" => false // If customizer is enabled, this will disable it for this field ) ) ) ));

Wherein sections wouldn"t need to be identified as we could create them on the fly.

Unfortunately this causes me a bit more work, but I think it may be the only way we can agree with everything.

Thoughts?

— Reply to this email directly or view it on GitHubhttps://github.com/SimpleRain/SimpleOptions/issues/23#issuecomment-23124618 .

@krishna19 I'm sorry I must have missed you.

The reason you can't install automated is your Xampp doesn't have SSL installed. So to bypass it you'll need to install the plugin directly.

Go to https://github.com/SimpleRain/SimpleOptions/releases and grab the latest release. Install it as a plugin and then voila, you should be good to go.

For you to develop locally you'll have to manually update the plugin. The automated updating is based off of SSL and your setup can't handle that.

@krishna19 If the problem persists, please open a new ticket and maybe we can skype some time.

SimpleRain / SimpleOptions

EVERYONE READ PLEASE - Need Advice #23

@dhechler @Smartik89 @teamcrisis @aristath @azharijelek @krishna19 @pe6o @tyl3r @syamilmj

$Simple_Options->add_section()

$Simple_Options->add_field()

If you want the class to do it for you then use:

$Simple_Options->add_fields()

$Simple_Options->add_sections()

Now what about...

If you want the class to do it for you then use: