Posts by Japh

373 posts WordPress Guy
  • Has referred 1+ members
  • Has sold $100+ on Envato Market
  • Has collected 50+ items on Envato Market
  • Located in Australia
+4 more
Japh says

I think you guys misspelled “CHICAGO.”

Yeah, maybe we’ll hit the east coast next time.

It’d be awesome to catch up with you again!

373 posts WordPress Guy
  • Has referred 1+ members
  • Has sold $100+ on Envato Market
  • Has collected 50+ items on Envato Market
  • Located in Australia
+4 more
Japh says

hmm… might have to intercept him as he flies over Europe :D

I’ll be stopping in Europe for WordCamp Europe on the way, actually. Meet you there? ;)

373 posts WordPress Guy
  • Has referred 1+ members
  • Has sold $100+ on Envato Market
  • Has collected 50+ items on Envato Market
  • Located in Australia
+4 more
Japh says

I’m very much looking forward to meeting those of you who can make it! Should be loads of fun :)

373 posts WordPress Guy
  • Has referred 1+ members
  • Has sold $100+ on Envato Market
  • Has collected 50+ items on Envato Market
  • Located in Australia
+4 more
Japh says

Hey everyone, I hope the following responses help provide some clarifications.

If I missed your question, or my response is actually more confusing than clarifying, I apologise and will happily clarify further.

Again, I apologise for the long reply, and the long wait, I didn’t expect 6 pages! ;)

====================================================================


Continue to my above question: If the theme must be running without my plugin, I think the metabox and options both need to in the theme. Otherwise the user just got a twentytwelve theme after they paid $30-50.

Agreed :)


I have two question though, and i’ll take a practical example to illustrate my concerns. Let’s take my theme WowWay. I have two custom post type, but let’s say that i’ll move all the functionality inside a plugin and do the following:

...

Maybe i wasn’t too clear, but i would definitely like to hear your input on these concerns of mine.

I agree with @ChapterThemes’ reply to you on this.


Assumption is the killer of all!!!

I have in-fact owned my own web design agency for 10 years now, we have well over 50 WordPress clients a year (Not much I know but I tend to not push WordPress due to it being heavy code) and not once have I ever been asked these questions.

Please don’t think I’m against this because I am not, I think its a good thing that users will have easy to switch theming but they are not the problem.

As every author on here knows, its the bad developers, who like to steal code, this just makes it easier to do this, because all they have to do is change a few variables and style them and voila they have there self some amazing functions.

I felt for sometime that authors have been taken for a mug a lot by some authors and Envato, and it just seems that we will get more frustrated by theft than we did before.

Envato in the past just say: “You are the copyright owner and you need to fight it”.

I think if you are making things more transparent for thieves then we need more help from yourselves!

You’ve been lucky not to have been asked then! :)

Regarding thievery, can you please elaborate on how you think this creates/exacerbates a thievery problem?


Question 1: Is it allowed to let a plugin check the current theme info and let it only work if the info matches the theme it has arrived with? Question 2: Is it allowed to require the theme purchase code as a setting before any of the plugin features work?

I would need to check this with the review team. Though I imagine if this kind of behaviour was acceptable, it would be better to do it by requiring the key to access the plugin prior to install, rather than having the plugin there but disabled.


basically when a user sets the Twitter Widget ID in the admin in one place, versus having to put that Twitter Widget ID in a input field in every Twitter Widget block.

This seems to me like it could be just as easily done in the plugin.


i can see how both possibilities they can do now, but it looks like that making the slider options into a plugin, just make it easier for people to just grab your code since now its portable via a plugin

I already am using TGMPA. How would you make it available on a server with a key?

Also what the point on making slider options into a plugin, when a user can not use it on another theme, since all the files for it to work on the frontend are in the theme itself??

thanks again JAPH !!

See @QBKL’s post above yours.


What made Envato/Themeforest what is it today is using “complete-website-in-one-for-$45” as a selling point, if they were simply skins from the start there is absolutely no way it would be as big as it is today.

This is an interesting point, because in my personal experience of assisting freelance clients with ThemeForest themes, this was certainly the original selling point, but it quickly became obvious that there was a lot more work involved in actually getting the theme to play nicely.


Suppose that I have one plugin that can handle all the functionallity, however when it is activated nothing shows, because I must initiate parts of it somewhere. Now the question I want to know if this is allowed, to init these parts inside my theme or I must create another plugin for this(let’s say “Theme Functions”).
Example:
Plugin Core: contains multiple PHP classes.
class My_Metabox {...}
class My_theme_Options{...}
class My_CPT{...}

Theme: Init these classes inside my theme so when the user activate my theme and if the plugin(Plugin Core) is activated it will show the options required for this particular theme:

if(class_exists('My_Metabox ') ) {
    $meta_options = array(
        //all options for my metaboxes
    )
    new My_Metabox($meta_options);
}
//A similar call for other classes: My_theme_Options, My_CPT, etc.
...

So, is allowed to do such calls from theme?

I guess it depends what you mean by ‘init’, but assuming you are describing something like WordPress’ add_theme_support(*) functions, that sounds sensible to me.

Essentially, the plugin has certain functionality that themes can then opt to support. The plugin then should display the configuration options for the aspects of functionality that are a) generically needed by the plugin, and b) that the theme has opted into.

The theme doesn’t need to do anything more than say to the plugin “Enable X functionality please, and I will provide styling overrides etc. for it, you handle the configuration”. Make sense?


Im not just randomly saying this. The reason i said that my slider options and theme options need to go in a plugin, in Phase 2 starting in November, is because that’s the answer Enavto Support gave me TODAY when i emailed them about it. They said they will be requiring all functionality, even theme and slider options and pages ported to a plugin. Thats what they told me. So thats what im going by!

Can you please provide me with the support ticket ID on this so I can clarify?


Can you please clarify an issue we are having regarding a support email reply we have received regarding these new requirements? The actual back-and-forth conversation is too long to post here but here is a snippet

Can you please provide me with the support ticket ID on this so I can clarify? The requirements are the requirements. If we change them, they will be updated.


So if a user installs and activates your theme and plugin and everything works fine, then switches to new theme, your plugin metaboxes and CPT no longer show? Is this the general idea?

If so, doesn’t that defeat purpose of making it a plugin to begin with? Plugin idea is to allow user to access the information no matter what theme they use. I think it should always show in backend, but maybe not do anything or not look good on the frontend if the plugin is activated on a theme you didn’t create it for.

Maybe I misunderstand what you mean.

This should definitely be taken into account. On deactivation, nothing should really be deactivated to the point that a user loses access to their data, surely?

373 posts WordPress Guy
  • Has referred 1+ members
  • Has sold $100+ on Envato Market
  • Has collected 50+ items on Envato Market
  • Located in Australia
+4 more
Japh says

Your mean is that: If the user does’t install my plugin, my theme still needs to be running. Just lose some featrues from the plugin. Is it right?

In most cases I would think that would be desirable, yes.

373 posts WordPress Guy
  • Has referred 1+ members
  • Has sold $100+ on Envato Market
  • Has collected 50+ items on Envato Market
  • Located in Australia
+4 more
Japh says

Any thoughts on what would stop another developer or user from stealing code from the easy accessible plugins? And do we have to make all slider options into a plugin?

Can you explain a little further the scenario you imagine them getting access to the plugins?

I can think of two possibilities:

  1. File access to the theme or WordPress install, and taking the plugins
    If they have this level of access, nothing is stopping them doing that now.
  2. URL access to ZIP file of plugins in the theme’s subdirectory
    An option would be to utilise a different method of distribution. Have the theme install the required plugins, via TGMPA (or similar), from a repository or server that requires a key. Soon, CodeCanyon will support this (as ThemeForest does), for example.

Thanks again JAPH for answering our questions so fast!! :)

My pleasure! :D


You recommend us to add the funactions via plugins as much as possible, so I want to know, if the user only installed my theme, but not installed my plugin. I will not let the theme run. Does it allow? Other words, the user must installed my plugin, then the theme will run.

Hi Matt! Ideally, the theme would “gracefully degrade”. That is, it will still work, but the functionality provided by the plugin will be missing.

As an example, let’s say it’s a restaurant theme, and requires a plugin that enables various custom post types (such as menus etc.). In this case, with the plugin disabled, ideally it should still look roughly like the general aesthetic of the theme, but it won’t have nicely styled menus, etc.

Does that make sense?

373 posts WordPress Guy
  • Has referred 1+ members
  • Has sold $100+ on Envato Market
  • Has collected 50+ items on Envato Market
  • Located in Australia
+4 more
Japh says

It’d be kind of nice if blockquotes were expandable and collapsed by default on long posts, wouldn’t it? ;)

(Sorry!)

373 posts WordPress Guy
  • Has referred 1+ members
  • Has sold $100+ on Envato Market
  • Has collected 50+ items on Envato Market
  • Located in Australia
+4 more
Japh says

Regarding widgets, I have placed all my custom widgets into a plugin.. But i have 3 widgets that i made that are dependent on data from my admin options. My contact info widget, my social widget, and my twitter widget. Basically in the widgets page the user just drags the widget over to the position they want it in, and the configuration info is in my admin options page, with links in those widgets displaing links to my admin page to configure. So those widgets i didn’t include in the plugin since they depend on data that is specific to the admin options i have in my theme. And those widgets share files that only available in my theme so i dont have duplicate code.

Will that be Ok, that these widgets are not included with my other widgets inside a plugin since the info from those widgets are dependent from my themes admin options?

This would be at the discretion of the reviewer. It’s difficult to answer this one, as I don’t know why your Twitter widget would be dependent on your admin options.


Is there any news on plugin authors being able to offer plugin licences for developers to use on multiple/unlimited sites?

No news yet, sorry.


So, why shortcodes must be in plugin? Shortcodes like dropcap, buttons, tables, columns, boxes etc. it’s all visual elements, not functional. They don’t provide any functionality, they just look.

Because the nature of shortcode implementation itself is functionality, and can impact the content of a WordPress install.


While reading this thread I can’t resist a feeling that envato market became slavish and dependend on various permisions instead of being free. Every post looks like “can I do this or that”, “is that allowed?”. Does it really matter to constantly ask for permisions to do anything instead of focusing on customer requirements?

I’m sorry you feel this way. I look at it like this: before, authors submitted themes without having a clear idea of what requirements reviewers were looking for; now the requirements are public, and authors are asking for clarifications based on these public requirements.

It wasn’t easy to ask “can I do this or that” or “is that allowed?” before, because the requirements weren’t known.

The situation hasn’t changed, besides increased transparency, which I would think is a good change.


Can we bundle required plugins in a separate folder and let users upload them individually? Or this is a space-mission task for users?

I would expect that could be a space mission that results in more support enquiries than if you used something like TGMPA to prompt users to do it through an interface.

You certainly could do it that way though :)


The big thing is that you can write something simpler to handle what you need. Otto has a great tutorial on this: http://ottopress.com/2012/themeplugin-dependencies/ Another thing is that writing competing code can often spur innovation. Many developers are interested in plugin/theme dependency these days, especially with things like CPTs, so limiting devs to using one class can actually stifle innovation in this area. Obviously, you’d want to check the code for security issues, but it’d be neat to see other solutions to the dependency issue.

Excellent points, and something we’ll definitely take into consideration as we discuss the specifics of this.



Curly braces requirement is nuisance, IMHO. Who says it improves overall readability? For me, it’s quite opposite – I have two braces more to “process” to figure out what is going on.

Agreed.

Just as a heads up, I leave off braces where appropriate in my Hybrid Core framework, so the themes that use it here would no longer be able to use it or would have change the code in the framework, which would defeat the purpose of using the framework.

Plus, WordPress PHP coding standards allow for no braces when you have single-line blocks: http://make.wordpress.org/core/handbook/coding-standards/php/#brace-style

This does appear to be a sticking point, and while I feel that omission of curly braces is against the overall rule of clarity vs brevity, perhaps we need to revisit this.


Is a _s based theme acceptable or not ? http://underscores.me/

Underscores is just a starter theme, I don’t see why using that as a starting point would be a problem :)


But at the end of the day, styling a theme is for the theme we have created, not to enhance another theme. Keeping data is one thing, making another theme look better and function better is another.

Im sure ThemeFusion will not want there shortcodes/functionality within other themes.

Dont get me wrong, I can see the benefits of this for the buyer, but I can see a ball ache for developers when users come back saying, it does not look right… Their past content from the theme the developer created on a new theme some other developer created, and vise versa.

Yes, styling is for the theme. Check out what ZillaShortcodes does.


From the 5 years Ive been on WordPress I have never had any support/client ever ask:

“Why is my shortcodes not working on my new theme”.

Or

“Why is my old portfolio not showing” etc etc etc…

When people buy a new theme, it generally is to provide a new presence and not to use old content.

As greenshady already mentioned, it’s not you who receives these sorts of enquiries. But as someone who worked in web agencies on WordPress sites for a number of years, I can tell you without any doubt, other people get asked. I got asked. Running a WordPress meetup group, I also see many users asking about this. It’s something that concerns them.

Why you’re not being asked at all though, I’m not sure.


Great. One of the reasons that I don’t want to use TGMPA is because everyone can download the zip files from my theme if they know the location. For “pirates” is enough to share one link in a public forum and we become, or to be precise, buyers becomes a distributor of ilegal plugin copies. If someone have a solution of how to forbid direct download then I will use this TGMPA for sure.

It could be done with access keys, and rather than package the ZIP in the theme, you serve it from a server that uses the access key to verify. However, something like this should be available on CodeCanyon in the near future (as it is with themes on ThemeForest now).


“Im sure ThemeFusion will not want there shortcodes/functionality within other themes.”

To put on the record, on day one of the first announcement, it came to us a shock purely because of deadline and buyer expectations. When it was clear that all already approved themes will have a much larger deadline since then we have been fully supporting the new requirements and will be following it, we have a much larger timeframe to support the WordPress and ThemeForest conditions and think about the changed workflow for our buyers.

We’re happy to follow and support them in the coming months.

Personally, as a developer, I am quite happy to work on these changes and write better code which in the long run will be beneficial to our business and our users.

Time to get creative guys. :)

- Muhammad Haris

Brilliant, Muhammad :D


Guys, congrats on taking this step and on working so close with the community to clarify and implement these changes smoothly. I’ve seen a lot of valuable feedback and even learned a lot from experienced developers and authors in these ~100 pages and am glad to see that authors that I personally admire and respect (some even know) are on board with these new requirements and even encourage them.

They follow good practice, push developers to be creative without being sloppy and put a clear limit between style and functionality. Also, they help educate clients and in the end, an educated client is a happy and much easier to deal with client. So, thanks Envato team and Japh particularly for “wasting” so much time doing an amazing communication job that at times has become frustrating and repetitive. Much respect.

As an aside – no promo intended – this recent video from Apple (Mission Statement) kind of reaches a few points of the whole “jam-packed” design/functionality debate that has been going on lately, although it has nothing to do with WordPress. Still, the principles apply: http://www.youtube.com/watch?v=VpZmIiIXuZ0

If everyone is busy making everything, how can anyone perfect anything? We start to confuse convenience with joy, abundance with choice. Designing something requires focus. The first thing we ask is: What do we want people to feel? Delight. Surprise. Love. Connection. Then we begin to craft around our intention. It takes time… There are a thousand no’s for every yes. We simplify. We perfect. We start over.
Words of wisdom. Have a good day/night everyone and may you sales skyrocket!

Nice link! I watched that video when they played it at WWDC, and I thought of ThemeForest and these requirements too. It’s quite inspiring :)

373 posts WordPress Guy
  • Has referred 1+ members
  • Has sold $100+ on Envato Market
  • Has collected 50+ items on Envato Market
  • Located in Australia
+4 more
Japh says

I’m off again for the night, everyone. Midnight seems to be my limit, but I’ll be back fresh again tomorrow if you have further questions or clarifications :)

373 posts WordPress Guy
  • Has referred 1+ members
  • Has sold $100+ on Envato Market
  • Has collected 50+ items on Envato Market
  • Located in Australia
+4 more
Japh says

To me, themeforest are basically not creating themes anymore…

They want us to create skins, with plugins.

For instance a theme has all logic and styling where as a skin has just styling.

Correct me if I am wrong?

For me this seems to be going away from WordPress standards, as WordPress state that all functions should be within the functions.php of the theme, yet we are now segregating them into a plugin.

Will prices go up?

I ask because this seems to be about 25% more work. and $35 – $45 is getting a little cheap when all this is being implemented.

This isn’t how I see things at all, and from a lot of the comments here, I think there are many authors who would also disagree with you on this.

A theme deals with the visual aspects of a WordPress install, and plugins add functionality. Sometimes there’s a certain amount of functionality required to implement visual aspects, so this level of functionality also lives within a theme. This isn’t particularly new. This is how WordPress has been doing it for roughly 10 years now.


To be honest, I’m on board with these changes, in the end they’re for the best, no-one likes change but we need to make sure we’re coding to the best standards possible.

I just have one question RE: the new policy on inline styles.

Let’s take this example: items in a loop which can have a background image (specifically) applied via post meta. Now to me the best way of doing this is to simply use an inline style on that element generated by the value of the post meta. I’ve read the mentions of wp_inline_style() but I’m not sure how this would apply to styles generated by post meta to be applied in the loop.

Basically I’m working on a theme where the user will have full control of the post background directly from the post meta for each separate post, colour or image, each post can be different including the colour, the image, and the image display.

Is it still ok to apply these post meta generated styles directly to the loop items, as this to me seems the best way of doing things :)

Hey Tom! The requirements say “No hardcoded inline styles are allowed anywhere. Dynamic inline styles are permitted where necessary, and wp_add_inline_style() should be used where possible.” (emphasis added)

I hope that answers your questions, as it sounds like it fits the scenario you mention to me :)


Japh, consider that we’re theme authors. Shortcodes will be moved into plugins because the new rules but you can’t expect fallback styling when plugin is custom made and used with a theme different from the one the it was bundled with.

That would be, honestly, asking too much. We use bootstrap in our themes, even the most simple shortcode (like a button) would rely on bootstrap css to render decently and we can’t inject whole bootstrap into another theme which is skeleton or whatever framework.

Same goes for javascript: almost all our code is commercial, made by us to be used with our themes only. While we will move shortcodes/custom post types into a plugin so all data will be available to the buyer in the backend when switching theme, the plugin itself will never include any of our custom js code.

Shortcodes will be rendered, markup will be there but its styling cannot be our concern.

Excellent point, and I think I also mentioned earlier, that I wouldn’t expect a plugin to include any CSS or JS if it relies on something as prolific as Bootstrap.

by
by
by
by
by
by