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.

So I have a question regarding creating a new database table for my plugin, the Easing Slider, which is getting a major overhaul.

Up until now, I've relied on update_option, get_option, and those various functions to save, edit and get plugin settings. It has worked well, but I've hit a slight snag.

So the plugins bigger, "premium" brother allows you to have more than one slideshow. This is done through saving a multi-dimensional array in a single option. I then have a function that select a specific array by the ID specified, which acts as the focal point for getting a specific slideshows settings.

The problem is, this plugin allows unlimited slideshows, each with unlimited images. Many users have been creating hundreds of slideshows, and the odd few are having problems at this point. As you can imagine, (for example) a 100 slideshows, each with 20 images, and each image with about 20 different settings, the one database option can get very large. As a result, for unknowns reasons, the odd user experiences issues and suddenly cannot create new slideshows or images, even though 'update_option' is reporting back true, letting us know that it has succeeded. One can only assume this is because the database option has hit its limit (possibly wrong, I've no idea why).

So I am looking into changing the way things work and using a custom database table. However, the one thing I can't get my head around is actually creating the table dynamically. The nature of the plugin is such that new features are added often, as well as removed. Filter hooks also allow users to add their own new features/settings easily. Each setting would ideally have its own column.

As a basic example, I could easily compile the ID's of the various settings into a single array. But could the database table be created from an array as simple as this?

$array = array( 'option_one', 'option_two', 'option_three' );
share|improve this question
1  
I highly doubt that you hit the limit on the options table which stores values as longtext and in mysql it means about 4,294,967,295 bytes ~4GB –  Bainternet Jul 3 '12 at 9:10

1 Answer 1

I would suggest using a custom post type to store your slideshows and then any custom features/settings can be stored as custom fields (in the postmeta table) for each slideshow and that would give you a native admin UI so all that is left for you to do is add your features/settings as metaboxes.

That is what i do with my theme's slideshows anyway :)

share|improve this answer
    
Thought about it, but really doesn't provide enough flexibility. Need a custom UI, and using a custom post type means jumping through hoops to try and achieve some of the desired functionality. It does have its advantages, but having to work around it rather than having direct control turned me off. –  Matthew Ruddy Jul 3 '12 at 13:51
1  
there is really nothing that youcan do with a post edit panel that you can do on a custom edit panel, love if you can tell me other wise? –  Bainternet Jul 3 '12 at 13:54
    
Nothing at all being honest, but it doesn't allow the same creative freedom with the panel layout, unless you want to re-style a lot of the Wordpress default classes and do a bit of hacking for including tabs for various settings pages. Plus, using meta options still requires having to filter through arrays to find specific slideshows and their settings. Similar process to using wp_options. A custom database table, where each column relates to a specific setting, is much easier to get information from. Each row is a slideshow, making it easy to quickly gather all its settings. –  Matthew Ruddy Jul 3 '12 at 16:10

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.