I’ve read over 25 pages of this thread. There is no specific answer for the Page Builders and some other core features.
That’s correct, we don’t have a specific answer on page builders yet. We’re working on it, taking all this feedback into account.
I would suggest to have a new category named “Wordpress Skins” instead of changing the current Themes. This marketplace releases the high-tech themes with amazing functionality. And those are unique functions. Not general. Wordpress Skins category can be just like HTML or PSD templates. Someone wants a regular wordpress theme without any functionality? He/she can buy the only skin. No plugins, no features, no shortcodes included. Purchase, download install and start to use just like you do with Wordpress’s default themes. You want a pricing table? Go buy a Pricing Table plugin. And that’s it. Lower price and only skin.
What you are calling a “WordPress Skin”, is a WordPress theme. Something with a lot more functionality integrate in, may not be simply a “theme” any longer, rather a turnkey solution of some kind.
So what’s the point in having a plethora of custom plugins that will become useless once the theme is switched ? How is this supposed to makes things better for buyers and authors ?
That is certainly not the solution we envisage. It seems to be a fairly narrow interpretation of what the requirements suggest, actually.
I do understand what Envato wants, but you should hear the authors as well.
That’s why I’m still here reading and replying
Yep, that’s how TGM works by default. I’ve used it previously and believe it or not, we were asked by plugin developer (if i remember correctly) to remove using TGM method due to licensing conflicts.
Interesting. What sort of licensing conflicts? That seems odd.
Anyhow, if I hack TGM to add the functionality of automatically installing and activating the required plugins, that won’t be an issue, right?
Why would you do that? Why not use the default functionality? If you fork the library, you will then have another thing to maintain, as features are added to TGMPA over time. Why not just have the banner saying they’re required?
I think it’s impossible to use that plugin across all one’s themes. As one theme should have the own features and it has the own css or php funcations. How does it across all one’s themes? We can’t ask the buyers to custom the css by themself. Otherwise should I make all of my themes have the same features and layout?
As was mentioned by someone earlier, what about “add_theme_support()” style functionality? The plugin handles various features, not all themes utilise them? Is this an option, or simple impractical?
Is it possible through TGM to automatically install and activate the plugins with the theme activation with the choice of user’s being able to disable them from the plugins option? Is that allowed or possible?
They won’t automatically install, but a banner will appear saying they are required by the theme for functionality, with a link to install them (either from included package, or the WP.org repository, presently).
On another note, if we package plugins in our download packages and we’re not GPL authors… are they covered by the standard Envato license, and therefore can’t be whipped off by others and used freely?
Everything in the item’s package is covered the license the item has, unless otherwise specified.
Envato should stop the non sense of the plugin concept and keep the rest, unless we are to add to every theme’s description “What you see is not what you get – you have download aaaaaall kinds of plugins for it to work”.
As has been said already, the theme should work fine without the plugins installed, just have reduced functionality.
It’s up to the theme anyways on handling the output of the plugins
But If I (authors) won’t update my old theme in next eight week, what would be happen?
Nothing until a bit further down the track, once the requirements list has had a few adjustments, when we begin the project to gradually ensure all existing themes comply with them too. There’ll be a LOT of notice given before we require this though, and we’ll work with authors to help the transition.
This is exactly what I was referring to in my previous post. It is not up to authors, such as Carlhancock or even Envato itself to decide what a “theme” is meant to be, it is the buyers who decide what they want for their cash. If you aren’t selling what buyers expect and want, care to hazard a guess as to what’s going to happen to Themeforest’s reputation and sales numbers? Currently Themeforest themes are turnkey solutions, you buy it, install it and bam you have a full website for under $50. And what has happened over time? Themes became more and more complete over the years and has led to more and more buyers buying themes. This being right or wrong doesn’t matter, it’s the reality of the TF market and changing themes to be more like “skins” would affect everything.
This is an interesting mentality… the problem is, buyers also want to be able to use the plethora of plugins and resources available for WordPress outside of ThemeForest. In that case do you believe buyers should choose one or the other? Either you have a WordPress theme from ThemeForest and accept that your site will probably break using outside plugins, or does ThemeForest make some changes to try and make their themes play nicely within the rest of the WordPress ecosystem?
What are your thoughts?
+1 I’m totally disappointed, no words 2 years of hard work, branding custom developed page builder and now I have to become a plugin developer instead of creating cool themes.
Why do you feel this is mutually exclusive? Why not convert your page builder into a plugin, and use that plugin across all your themes? Is this really such a terrible change for you? I genuinely want to understand the issue for you here.
I agree with you. Until now it has 360+ replies. I think it will not make any changes. We can all stop to talk about the topic. All are going to sleep.
These 360+ replies will be the basis for the first round of changes to the requirements list. We’re not going to make an adjustment after each of the 360+ posts But trust me, we are reading and listening and trying to understand so we can make this work for everyone.
3. Themes will be required to use whichever version of jQuery ships with that version of WordPress.
4. Authors are not allowed to deregister the default version of jQuery and load another one.
Whats wrong if we use the newer version of jquery?
There’s no need to do so, and it means you’re using a version of jQuery that’s not been thoroughly tested with WordPress. Considering how often WordPress updates, is there really some new feature in jQuery that you can’t wait a few months to have available? Surely not!
How should i rewrite this theme with plugins?
I’d love to sit down with you on Skype sometime and work that out! Good real-world case for you to demonstrate some of the points from this thread to me.
If the implication here is that a problem has been created regarding the number of CSS and JS files, that is very easily rectified, by any customer who cares to do so, with a caching plugin. Again, this is why standards are important, as loading CSS or JS files in a non-standard way would mean this solution wouldn’t work.
And why TGM? Envato need own solution for this, solution that we can base on. If whole marketplace need split themes functionality to plugins and pack them with themes You can’t relay on some else to do this.
Because TGMPA already exists. Why duplicate effort? Why not contribute to something that already exists so everyone can use it? If it so happens that Thomas decides not to continue maintaining it, it’s open source and we can continue to maintain it ourselves.
Are you not relying on WordPress itself in much the same way already?
Just a quick question. Can we use social links (twitter/facebook etc) in the theme to share the posts? These links use iframe to display their buttons and you get the “INFO” message that the iFrame has been used.
Considering the number of plugins available that do this, I’d be interested to know why you’d want to?
Can I include all my functionality in one plugin or will it need to be different ones?:
one restaurant pack plugin
vs1 plugin for food menus
——1 plugin for reservations —- 1 plugin for specials & promotions
Assuming the functionality makes sense together, this is exactly what I would expect. A restaurant plugin that gives all restaurant functionality to a theme that supports it.
Another questions: Is it OK to pack your own set of plugins inside the theme folder for buyers to upload and activate? Like said in the TGM instructions:'source' => get_stylesheet_directory() . '/lib/plugins/tgm-example-plugin.zip', // The plugin sourceDoes this mean every theme folder will be packed with plugin files? If so… is that a good thing since a plugin should be in de plugins folder ?
Yes, this is ok, and no that’s not how TGMPA works. The plugin is installed from the packaged location into the plugins directory by TGMPA.
CodeCanyon is great, but I don’t think it’s a viable solution here. If I’m a user and I buy a theme on TF that has some certain functionality, then I find out I have to buy a plugin on CC, I’m going to be very upset. Selling functionality twice is very dishonest, IMHO.
It would be dishonest, and it’s not what I’m suggesting. In this scenario, the theme would say something like “supports X functionality with [linkhere]Plugin Y[/linkhere]”. Modularity FTW!
Japh saidPersonally, I think it a wash. You can make valid arguments for and against its usefulness.
I’m actually surprised this wasn’t raised earlier in the discussion. It seems to make a lot of sense to me, I’d be interested to know more about you guys’ thoughts on it. Why might you think this isn’t easier / better?
What are the valid arguments against?
I believe scripts should ideally be loaded with no protocol specified ex://domain.tld/filename.ext, but keep in mind that that doesn’t work on local (MAMP-based) servers where the protocol isfile://dir/dir2/filename.ext.
Unless you configure your MAMP server to support it
Because as Siddarth stated above, the reason you’re doing this in the first place is flexibility and modularity.
Hmmm… that doesn’t make sense to me… using CodeCanyon is just as flexbile and modular!