Can anybody help to explain then, if we have to use plugins for functionality, what happens to a wordpress install when you have a large qty of plugins, i.e 20 or more ? it slows it down, right?
what about, for example a theme author is using the visual composer plugin ?
what about wordpress default visual theme customiser and theme options pages that reply on inline styles ? a styles.php would have to be used correct?
i dont think these new quidelines have been thought out carefully .
Looks to me we are all REQUIRED to go the way of the woo.
ive created an updated screenshot for authors to make use of, leaving credits intact would be appreciated.
wouldnt that just be using someone elses code then? cant see you getting paid for something thats already free and readily available to those that can read
in honesty i dont think you’ll have any issues with these errors, i recently carried out a theme check on an elite authors template and it threw up ALOT of errors including timthumb, ive also seen premium themes php warnings suppressed rather than fixed.
just get users to donate theirs, im sure they wont mind in return for a little support and a credit in a txt file
best ive seen is shortcode ninja by woo, although a plugin and make to work with woo only themes im sure you would be able to make it work with a little fiddle, ive managed it in my theme
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 itAs 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.