366 posts WordPress Guy
  • Has referred 1+ members
  • Has sold $100+ on Envato Market
  • Has collected 50+ items on Envato Market
  • Member of the Envato Team
+5 more
Japh Envato team says

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.

20 posts
  • Has been part of the Envato Community for over 1 year
teamCrisis says

Japh,

Generally speaking I think these new requirements are needed and thank you for better explaining them. I do have additional questions:

1. Must we use exactly TGM activation class or can we use our own?

2. What about custom widgets? Must they be plugins or within theme? I don’t see anything about it.

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?

33 posts
  • Has been part of the Envato Community for over 2 years
  • Has collected 1+ items on Envato Market
  • Sells items exclusively on Envato Market
  • Located in United States
JonnyShogun says


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.

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?

thanks!

2002 posts
  • Has referred 50+ members
  • Has sold $500,000+ on Envato Market
  • Has collected 10+ items on Envato Market
  • Elite Author: Sold more than $75,000 on Envato Market
+9 more
bitfade says

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 :)
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”

366 posts WordPress Guy
  • Has referred 1+ members
  • Has sold $100+ on Envato Market
  • Has collected 50+ items on Envato Market
  • Member of the Envato Team
+5 more
Japh Envato team says

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.

139 posts
  • Made it to the Authors' Hall of Fame
  • Had an item featured on Envato Market
  • Elite Author: Sold more than $75,000 on Envato Market
  • Has collected 1+ items on Envato Market
+4 more
Cubell says

Japh, three more questions:

1) do things like registering custom sidebars and adding image sizes (custom thumbnails) need to be moved to a plugin as well?

2) Can we create a single plugin that creates all the meta boxes, custom post types, etc and then within the theme actually manipulate the data the user inputs in those meta boxes? Example: The plugin creates a meta box for a review system (Criteria inputs, scores inputs, etc). Then within the themes we write the css + functions that grab the data and do whatever with it.

3) If we put all functionality in one plugin and set the plugin to be “forced activated” using TGM, then the theme would load everything and be exactly the same as it is now, with the one difference that buyers will be able to change themes and still see the data they inputed into review meta boxes, custom post types, etc, however, the data is now meaningless and only there for them to easily copy and paste to their new theme’s meta boxes, seeing as the functions/css that manipulated that data was integrated in the previous theme. This is how I can see this all working. Is this how you want it to be?

Thank you for clearing this up.

33 posts
  • Has referred 10+ members
  • Has sold $40,000+ on Envato Market
  • Has collected 50+ items on Envato Market
  • Has been part of the Envato Community for over 3 years
+2 more
whoathemes says

@japh

What about custom theme widgets and metaboxes. I have 15 theme widgets in my framework including the widget for Twitter. All this widgets should be put in a plugin and the twitter widget in a separate plugin?

I also have metaboxes for every page / post below the editor with General Options for Page alignment, custom sidebars, header types etc. The same, another metabox for Backgrounds with options for every page / post header bg and color, content bg and color, footer bg and color and so on. All of these should be part of another separate plugin? There will be errors in pages because nothing from the above won’t be recognized because that plugin is not activated. How can we handle this thing?

Thanks

366 posts WordPress Guy
  • Has referred 1+ members
  • Has sold $100+ on Envato Market
  • Has collected 50+ items on Envato Market
  • Member of the Envato Team
+5 more
Japh Envato team says

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.

366 posts WordPress Guy
  • Has referred 1+ members
  • Has sold $100+ on Envato Market
  • Has collected 50+ items on Envato Market
  • Member of the Envato Team
+5 more
Japh Envato team says

1) do things like registering custom sidebars and adding image sizes (custom thumbnails) need to be moved to a plugin as well?

No, these belong in a theme.


2) Can we create a single plugin that creates all the meta boxes, custom post types, etc and then within the theme actually manipulate the data the user inputs in those meta boxes? Example: The plugin creates a meta box for a review system (Criteria inputs, scores inputs, etc). Then within the themes we write the css + functions that grab the data and do whatever with it.

That sounds fine to me, yes.


3) If we put all functionality in one plugin and set the plugin to be “forced activated” using TGM, then the theme would load everything and be exactly the same as it is now, with the one difference that buyers will be able to change themes and still see the data they inputed into review meta boxes, custom post types, etc, however, the data is now meaningless and only there for them to easily copy and paste to their new theme’s meta boxes, seeing as the functions/css that manipulated that data was integrated in the previous theme. This is how I can see this all working. Is this how you want it to be?

That sounds right to me. Also, you left out the scenario where you made more than one theme for this particular niche, and they were able to switch between your themes without losing any data and having everything still work on the frontend too! (Yes, perhaps this was possible without plugins before, but it will be a much cleaner separation now)


What about custom theme widgets and metaboxes. I have 15 theme widgets in my framework including the widget for Twitter. All this widgets should be put in a plugin and the twitter widget in a separate plugin?

Custom widgets and metaboxes that are theme-dependent are fine within a theme. Twitter functionality should be separated out, and then a Twitter widget can hook into it.


I also have metaboxes for every page / post below the editor with General Options for Page alignment, custom sidebars, header types etc. The same, another metabox for Backgrounds with options for every page / post header bg and color, content bg and color, footer bg and color and so on. All of these should be part of another separate plugin? There will be errors in pages because nothing from the above won’t be recognized because that plugin is not activated. How can we handle this thing?

Custom widgets and metaboxes that are theme-dependent are fine within a theme.

366 posts WordPress Guy
  • Has referred 1+ members
  • Has sold $100+ on Envato Market
  • Has collected 50+ items on Envato Market
  • Member of the Envato Team
+5 more
Japh Envato team says

Ok everyone, I’m out for the evening (it’s 12:04am here). Going to have to go and get some sleep, if my baby daughter will let me.

I’ll be back in the morning to answer any other questions you may have. Sid from the review team will also be around to answer questions.

Thanks for your feedback and questions so far! :)

by
by
by
by
by
by