I would argue that WP doesn’t need a standard plugin to handle shortcodes. What WP needs is a standard list of shortcodes that all themes support.
I couldn’t disagree more. Shortcodes are a great example of why they should be put in plugins and not in themes. There are shortcode plugins in the WordPress directory that ship with default styles set up. Some of the smarter, IMO , plugins even allow you to supply your own stylesheet in place of the plugin-supplied css file in the event you’d like to have complete control over how the shortcodes are styled. IMO that’s the superior approach. Themes can offer a custom, integrated look, but if/when the user changes themes, if built-in support is not included in the new theme, the plugin would revert to its base CSS . That way the shortcodes still work and the user doesn’t have posts and pages litered with broken shortcodes.
I would like to point out that using CPTs isn’t adding functionality.
Tell that to e-commerce plugins.
they just aren’t flagged as posts. So, change that DB field back to “post” and you instantly have access to all of your previous CPT content under the Posts section. Problem solved.
The problem isn’t solved by that method though… it’s actually made more complicated because now you have “staff” or “FAQs” or “products” mixed in with “posts”. And if there’s custom meta data or taxonomies with those items, now that’s all mixed in as well.
By saying that themes shouldn’t use CPTs, it feels like clipping WordPress at the knees. That functionality is there for a reason.
WordPress is powerful and extensible enough that a plugin could be written to behave like a theme and vice versa. Just because a theme author can add CPTs doesn’t mean they should.
Content is content and style is style. The parts of WordPress supplying the content should largely be kept separate from the parts of WordPress supplying the style. You’d be hard-pressed to find even an edge case in which a compelling argument could be made to support a theme author supplying a CPT , especially one which is visible from the front end of the site.
I doubt you’ll find a consensus on the “best platform” because that is such a subjective item. I use and love Genesis by StudioPress and it’s almost the polar opposite of what you describe—it has much less flash and far fewer settings, but once you get the hang of developing with it, it’s very powerful.
ThemeShaper saidI hardly think that’s worse than after switching themes, looking at pages and posts with
The problem is, unless the plugin is the same across lots of different themes (and theme authors) users will still have mostly useless shortcodes upon switching a theme. That isn’t to say all would be useless (things such as columns would still work) but at best you would have a theme with working shortcodes obviously styled for a different theme.
[shortcode] content [/shortcode]sprinkled throughout. Even if the shortcodes do not have an integrated appearance, at least they’d still function.
As I mentioned to Steven earlier, I’ve got some ideas about this type of thing. A standard portfolio plugin is at the top of my ideas list too. Maybe I can get my blog post up in the next week or so about it. But, if you want to start up a new thread here in the forums and nail down some ideas about how portofolios should be handled, I’ll be more than happy to help out with it.
I’ll gladly contribute my portfolio plugin as a jumping off point—http://arcnx.co/ap
pixelentity saidNonsense. TF theme authors could easily code a plugin for use with their themes in which the CSS and JS necessary to power the functionality could be overridden by including specific files in the theme directory itself. It actually makes it easier for TF theme authors this way since authors can offer a consistent operational experience across all of their themes from a single plugin codebase, and yet still offer each theme a specialized look for that functionality.
Which is why it will never work: complex shortcodes like gallery, slider, filterable portfolio requiring all kind of custom css/js.