4 posts
  • Bought between 1 and 9 items
  • Exclusive Author
  • Has been a member for 7-8 years
  • Sold between 100 and 1 000 dollars
  • United Kingdom
Rhys-Works says

Hi :)

I’ve been working for some time on a PHP framework of sorts for WordPress, designed to allow a Theme or Plugin creator to very easily and quickly generate complex backend options pages to supplement their theme/plugin. The framework would then be bundled with any theme/plugin you ship, etc.

It’s all XML -driven in order to be very easy to use, and comes with a frontend templating system attached – e.g. if you added a banner carousel to one of the options pages on the admin side of things, you could then easily in your header.php add something like get(“myCarousel”, “withNiceShinyCarouselHTMLandJavascript”); and have it echo out onto the page without you needing to do this manually (obviously, it’s customisable should you wish).

It’s designed to be very simple to install and use, but i’m still developing it at present. I’ve been giving some serious thought to making it exclusive to ThemeForest/Envato, and was basically first looking for feedback from the community as to desirable features in such a product.

What kind of things would be a major priority to you as a developer? Vast quantities of form options? (ie carousel selectors, WP media center integration, CSS choosers/editors…), customisability? Lots of bundled, ready to use templates out-of-the-box? Speed? Do you care that it can run purely off XML input? etc.

Any thoughts and/or suggestions from the community would be great.

Thanks

3058 posts
  • Community Superstar
  • Has been a member for 6-7 years
  • Won a Competition
  • Sold between 50 000 and 100 000 dollars
  • Bought between 10 and 49 items
  • Referred between 50 and 99 users
  • Exclusive Author
+1 more
wickedpixel says

Why XML and not database? The ideal way should be that options can be saved, imported, created and structured from the admin gui…

4 posts
  • Bought between 1 and 9 items
  • Exclusive Author
  • Has been a member for 7-8 years
  • Sold between 100 and 1 000 dollars
  • United Kingdom
Rhys-Works says

Ah, let me be clear: You write XML files to power the creation of the option pages, e.g.

<SliderElement> <Range> <Min>0</Min> <Max>100</Max> </Range> </SliderElement>

This would create a simple slider element on one of your option pages, but the data saved into that form goes into the Wordpress database like any normal Wordpress option.

As for how options are created: At the moment, you make an XML file that is then parsed by the PHP script. The reason this isn’t done in the admin GUI is because as a developer, you don’t necessarily want to expose that kind of functionality to the eventual user.

However, i’ve implemented a ‘developer/debug’ mode, that when turned on presents you with extra useful info and control. I could adjust this so that you can edit the XML live on the admin GUI – i’ve actually been considering writing a live validator for it, that will give you feedback on your input immediately.

The eventual evolution of this I think is to have the XML files be generated by some kind of GUI interface that would allow you to visually drag and drop/edit options. That’s really something that would depend on whether people were very interested in having it available, since that’d be a pretty big feature.

Thanks :)

3118 posts
  • Sold between 5 000 and 10 000 dollars
  • United States
  • Bought between 10 and 49 items
  • Has been a member for 3-4 years
  • Exclusive Author
chrisakelley says

Sounds like a mess that follow no WordPress conventions at all….... Not a good practice at all….

Great that you can something like that but for WordPress it’s not appealing at all

4 posts
  • Bought between 1 and 9 items
  • Exclusive Author
  • Has been a member for 7-8 years
  • Sold between 100 and 1 000 dollars
  • United Kingdom
Rhys-Works says

Well, there really isn’t any WordPress convention for setting up options pages, the last I checked.

Most themes that i’ve seen dump static HTML into a PHP file in order to build options pages on the backend. That’s not an ideal solution – hence this method, which would make generating them a lot easier. It provides a function for WP that doesn’t exist natively that (from experience, which is why i started developing it) is a major time-sink during the theme development process, and a pain to alter once it’s set.

As for WordPress conventions, it uses the WordPress hook API extensively, which developers can take complete control over. The templating system is also not dissimilar to various WordPress functions such as the Walkers, which themselves do a certain amount of HTML decorating.

You also by no means whatsoever have to use the template system – you can drag the values out of the database in the exact same way you would with normal WP options – which is entirely in keeping with WP convention. It’s just an extra option to make things easier.

It’s designed to play nicely with WP and take advantage of several of the major WP conventions. The XML side of things might scare some people, but like HTML in general, it’s a natural abstraction of what is otherwise a tricky design/construction process. I would argue that it supplements WPs functionality – it’s not trying to overwrite or rewrite anything, it’s supplying something to WP that just isn’t there to begin with – and it’s really very easy to use, I promise ;)

Let me give you an example scenario:

Your user wants to be able to set a banner rotator on the homepage. They want to be able to use images imported from the WP media center. They want to be able to edit/crop the images. They want to be able to set the order in which the images will be displayed by dragging and dropping the image/rows around, and they want to add customisable text to go along with the image, like a caption, and a heading. They want to be able to see all the items in the banner rotator on the admin pages and control them from there.

On the frontend, they want to be able to choose whether the banner rotator is displayed with CoinSlider.js or NivoSlider.js. And they want the whole thing to be pretty, using ajax controls to edit this information.

I currently have this functionality set up with about 5 or 6 lines of XML , then one import statement in header.php. It’s completely dynamic – you can change any of the above requirements at any time by editing a line or two of XML and the whole thing will update, from the back to the front. To do this in traditional terms in WP would be a lot more work. Of course, it can also do other similarly complex actions, this is just an example.

Why XML ? Well, because it’s absurdly easy to use. That’s the point. It’s also an obvious choice – this kind of building-block process is what XML was invented for, much like HTML /XHTML.

If that kind of extra power in your theme creation isn’t something you want or need, or you have a better way of doing it, then i totally understand. I’d be surprised if some devs wouldn’t find it useful, though :)

Thanks for your input :)

3118 posts
  • Sold between 5 000 and 10 000 dollars
  • United States
  • Bought between 10 and 49 items
  • Has been a member for 3-4 years
  • Exclusive Author
chrisakelley says

Erm…... http://codex.wordpress.org/Settings_API

Also Note the theme customizer http://wordpress.org/news/2012/04/wordpress-3-4-beta-1/

Also who cares if XML is easy if it doesn’t follow WordPress conventions its simply bad practice aka will break plugins, themes and possibly the core….

4 posts
  • Bought between 1 and 9 items
  • Exclusive Author
  • Has been a member for 7-8 years
  • Sold between 100 and 1 000 dollars
  • United Kingdom
Rhys-Works says

We’re misunderstanding each other. The code uses the settings API for various parts of its functionality. When I said there’s no convention in WP for this, I was referring to actual full lifecycle implementation of complex WP options – which the settings API does not provide (it’s just a means by which to implement your own featuresets – which is what my framework does).

The XML input wouldn’t break anything. It’s just input – once it’s in WP, it obeys ALL of the standard WP conventions. It’s invisible as far as any other native or external WP functionality is concerned. It just provides a very simple way to get complicated instructions into WP, but it goes in the exact same way as any other options would. In fact, if you don’t like XML , you can write all of this in PHP function calls. It’s just easier to do it in XML , that’s why I added it ;)

As for the WP theme customizer: there’s some cross-over, but without getting too much into it (for the sake of brevity) the two things address a lot of different problems.

FirestormGraphics
FirestormGraphics Recent Posts
Threads Started
38 posts
  • United Kingdom
  • Has been a member for 3-4 years
  • Bought between 1 and 9 items
  • Exclusive Author
FirestormGraphics says

We’re misunderstanding each other. The code uses the settings API for various parts of its functionality. When I said there’s no convention in WP for this, I was referring to actual full lifecycle implementation of complex WP options – which the settings API does not provide (it’s just a means by which to implement your own featuresets – which is what my framework does).

The XML input wouldn’t break anything. It’s just input – once it’s in WP, it obeys ALL of the standard WP conventions. It’s invisible as far as any other native or external WP functionality is concerned. It just provides a very simple way to get complicated instructions into WP, but it goes in the exact same way as any other options would. In fact, if you don’t like XML , you can write all of this in PHP function calls. It’s just easier to do it in XML , that’s why I added it ;)

As for the WP theme customizer: there’s some cross-over, but without getting too much into it (for the sake of brevity) the two things address a lot of different problems.

bung it on github as beta and test the water :) cant see being a big hit realy, theme options are losing favour with devs nowadays, look at woo they opted for portability of a plugin instead.

by
by
by
by
by
by