1. Must we use exactly TGM activation class or can we use our own?
Our preference is for TGM Plugin Activation for the sake of consistency, and it’s a robust existing class. However, I will discuss this with the review team.
2. What about custom widgets? Must they be plugins or within theme? I don’t see anything about it.
I think this would be on a case-by-case basis. Let’s lean towards plugins for functional widgets, and themes for aesthetic widgets.
3. You say that modification of wpautop is not allowed. Do you mean it’s not allowed at all under any condition, or do you mean it can’t be modified globally? What if I want to modify it for only a few shortcodes, but not on a global basis?
If you can find an absolutely safe way to do it on a few shortcodes only, please share with us.
So basically when you say put taht functionality into a plugin.. does that mean i have to make a wp plugin for each thing. Like creating a plugin for just shortcodes, a plugin for custom post types, and a plugin for twitter api. Cant i just have all these in ONE plugin?
If it all relates to a single purpose, then I don’t see why it couldn’t be in one plugin. Such as my earlier example of a real estate plugin. However, some of these things should be more modular because they’re more generic and you need them to be more portable.
I was talking about custom metaboxes which, according to your replies in this thread, should be moved into plugins in phase 2. My point is that plugins should implement common features (as in, a project custom post type) but theme specific custom metaboxes should still be defined in theme (as in, “layout: media|content, media/content”
I would say for theme specific metaboxes, relating to layout and content etc., this would be fine to be in the theme.
As of today, we have a component that defines a Portfolio CPT, registers it, and is integrated with our theme framework that manages custom metabox saving too, among many other things.
If we were to create a plugin that implements a Portfolio CPT, following your guidelines we should insert the metabox creation logic and saving right in the plugin.
Also following this logic, we should duplicate these functions in each and every other plugin of ours that defines a custom metabox, otherwise when switching between themes you wouldn’t be able to actually see the metaboxes, nor save them.We feel like this would be like duplicating a lot of code when the very same thing is already achieved by our current framework, in one place, under SVN version control.
Could you not move this logic into a custom metabox plugin, and then all your custom post type plugins utilise that for saving metaboxes? Wouldn’t that avoid the code duplication issue?
You might observe that we could put our whole framework in a plugin, yet the frontend part of the CPT implementation would still be missing.
Yes, the frontend part would be missing, however the customer would still be able to access their data in the backend, rather than have it completely vanish from sight.
We understand the concept of enhanced scalability and the fact that’s good for all the players in the game, yet why should we sacrifice code reusability in the name of a modularity that some of us might have already found without involving plugins? We think that the final customer buys an author’s theme because of its design and functionality, not to be able to randomly switch between themes at will.
I’m sure there’s a way to do this that doesn’t involve sacrificing code reusability, and still achieves a good separation of design and functionality. I’m certainly not implying that customers will randomly switch between themes. In fact, it’s customers that have stayed with a single theme for a long time, and now want to switch, that will be most hurt by the issues we’re trying to resolve.
Great Japh ! I’ve spent few days to solve the issue with new twitter API a month ago, updated all the themes since I have the option even with a shortcode and separate widget also… And now the things are changing again?... A separate plugin only for twitter which should not use cURL? Thanks guys… seems that all my work and another author’s here was for nothing…
I’m sure your work hasn’t been for nothing. You need only must remove cURL from your theme. Moving the Twitter functionality into a plugin will achieve that.
It would be much better to use
wp_remote_request() instead of cURL, but that’s not strictly a part of these requirements.
Japh, themes will need to define custom meta in one way or another and the only way envato can prevent this is by forcing authors to create specialized plugin version where custom metas are defined exactly like theme needs them (and you don’t wanna do this)
Because if the plugin is “general” as in it comes with its predefined sets of custom meta for each custom post type but it offers themes hooks that can be used to replace defaults with custom data, strictly speaking, the meta itself will still be defined in the theme rather than in the plugin.
Consider a very simple scenario: theme has “home” custom page template with optional call to action message area on top. This can be easily done with a custom meta, has nothing to do with shortcodes or custom post types and would be only used in this theme so why this meta should be defined in the plugin instead ?
Perhaps we are not talking about the same thing? Apologies for any confusion. If you can clarify your question further, I’ll do my best to answer it
So are you basically saying that i would have to include this twitter functionality as a plugin, right?
And i would have to modify the twitter oAuth 1.1 php to not use curl?thanks again for the quick reply!
That’s basically what I’m saying, yeah. I’m actually currently in the process of making a plugin myself that uses Twitter’s oAuth API v1.1, and that’s what I’ve done.
What happend when existed items failure to comply all requirements? Will be removed from TF? Im asking because my first theme is “ready” to upload, but fit to new requirements is a lot of work and I dont know if I want spend time to change my theme (especially moving logic to plugin)... so I dont know I its better to sell this theme on other marketplace or what. (sorry for my english)
Hi Peter, we have no timeline in place for when existing themes will need to comply with these requirements, other than it will be a minimum of 6 months or more.
If and when the time comes, we will work together with authors gradually, as stated in the Notes post.
What about the new Twitter API oAuth.. it uses curl. So what do we do about that since the new Twitter API since in order to use the new twitter requests, you must use there new API oAth files. You have to setup a Twitter developer app to use with the new Twitter APi which uses curl. So will this be a problem???
You’re referring to example PHP files, which can be modified for use in a WordPress context, and will work just fine. Even so, this functionality should be in a plugin.
One of the things that kind of worries me with moving everything to plugins, is that if something breaks in one plugin because of naming convention for example, the site will become unusable. Even with a unique prefix, there are quite a few authors here, and if there’s a couple of themes installed, I think that naming conflicts will be an issue. Maybe a larger problem then what you’ll anticipate…
This isn’t really any different than if something breaks in the theme. In fact, it’s easier to troubleshoot because it’s nicely separated out.
And then there’s always an issue of pageload times. With an increasing amount of plugins and shortcodes in plugins, the_content() will eventually start running very slowly, since there’s quite a bit of regex involved.
Again, there is no additional performance hit for moving this functionality from the theme, into plugins.
You stated “Authors are not allowed to deregister the default version of jQuery and load another one.”
Am I allowed to deregister the local, and load the same version via cdn?
There’s really no need to do this, and it creates an additional unnecessary dependency.
- Another one
” If a CDN version of a library is included, a local copy must be provided as a fallback. ” If I’m loading a well known library via cdn , should I also include a local copy in the download files and that’s it, or there are some additional steps that must be taken to comply for that rule?
When we say provide a local copy as fallback, we mean using a mechanism that automatically falls back to the local copy if the CDN copy fails to load. Not simply providing it with the download package.
I have good feeling about Themeforest marketplace since Envato hired you, good move Japh
You’re too kind!
Anyway, how about theme customizer http://codex.wordpress.org/Theme_Customization_API Does this feature should be on theme or plugin?
This should be in the theme. In fact, this is a great way to do any visual options for a theme.