Posts by ChapterThemes

616 posts
  • Bought between 10 and 49 items
  • Exclusive Author
  • Has been a member for 3-4 years
  • Sold between 10 000 and 50 000 dollars
ChapterThemes says

@ChapterThemes, I am sorry to disagree with your way of seeing things, but IF the issue is within your plugin’s CODE, its functionality, it falls on your shoulder to fix it, no matter the theme it gets applied to. If you have a poorly written PHP or JS block that causes the thing to crash, it is your responsibility to fix it, just as it is now. And that’s how it should be fair both to users and for a respectable author. Again, and I need to reiterate this -> IT WOULD NOT fall on your shoulders to fix design/styling issues of your plugin in another author’s theme, as long as the mechanism of the plugin works perfectly. Let me give an example:

You create a tab shortcode functionality. User switches themes. Tabs stop floating, lose colors and whatever else you want from the styling, BUT they retain the translation from shortcode to visual HTML, maybe even the JS actions of clicking to show each tab.

- OR:

A buttons shortcode will return a simple unstyled A tag, instead of one using predefined color, backgrounds, border-radius and so on.

These two examples SHOULD NOT fall on your shoulders as to support and to update to a user’s new theme. Catch my drift?

Well in this case you don’t totally disagree with me.

Like i said before – it’s easy to supply simple function styling so that every feature keeps working but in a very basic form. And have theme-related styling inside the theme stylesheet.

Also, when discussing this, i talk about good coded themes and plugins ofcourse.

People worry about lame simple things as column shortcodes, tabs? Hell those things are like a gazillion around – those are not features that make a theme unique.

I do however have the oppinion that advanced super features for some niche theme should not be portable as a fully working plugin inside other themes – EXCEPT if the theme price will go from say 45 to 70 bucks – since then people will also purchase a plugin which they can fully use.

But i’m just debating some points here, trying to get an answer and see how other think about it.

I myself see no problems as i already know how i’m going to set things up: Already since a while i’ve been working on a set of super plugins. Besides that i’m working on beautiful themes that work perfectly and look nice with my own plugins. Plugins go on Codecanyon, themes go here on TF :) a voilà, besides the fun of creating – i see business

616 posts
  • Bought between 10 and 49 items
  • Exclusive Author
  • Has been a member for 3-4 years
  • Sold between 10 000 and 50 000 dollars
ChapterThemes says

—code in a plugin will be portable and easier to steal. What protects us from this misue?

What protects you from a person using a theme 20 times? What protects anyone who want to steal code from a plugin or theme?

: Nothing. Never will be since in every case they get the sourcecode.

This is always been the case even with themes without plugins.


—since its a plugin, are we responsible for the plugin working in other themes? (with the exception of shortcodes markup staying intact)

Ofcourse not. Like i said above: buyers also need to know the rules.


—if a user switches themes, some functionality wont be on the theme they switched to because all the js, css supporting it will be in our theme?

Depends, if you code your plugin correctly the plugin has it’s own js and css files. You could always define the very basics inside the plugin, and theme-styling inside the theme.


—if we are using the TGMAC, can we set the plugin to force deactivate if the user switches the theme so are plugin is only used with our theme? (with the exception of shortcodes)

You can put in a theme info check inside plugins to only work with a certain theme or you could also use a purchase key check or something. – don’t know if thats allowed btw. Waiting for response for that in an earlier question.


—So now it seems we are now becoming plugin developers and will get no compensation since the plugins we make that are specific to our theme, will now be used in other developers theme. And we will have users who buy our theme, why someone else’s theme plugin is not working in our theme.

Maybe you can see the whole thing as an opportunity to get more payed work. Buyers want a plugin from your theme to work in another theme? That’s possible, for a certain amount maybe…

616 posts
  • Bought between 10 and 49 items
  • Exclusive Author
  • Has been a member for 3-4 years
  • Sold between 10 000 and 50 000 dollars
ChapterThemes says


There was another question about who’s going to offer support for the plugins that persist beyond your theme. The way I see it – and this works well with that bitfade said above -giving support for that plugin falls on your shoulders, as the client paid for what he got, BUT with a twist. After theme-switch (except cases where users switch to a theme from the same author), the author COULD or SHOULD only provide support for functionality issues, not styling issues. For styling issues it falls on to the client to support the consequences of their decisions, thus to pay either the author or a freelancer to restyle the plugin in line with their new theme.
+1. When a buyer switch themes he will stuck with, lets say a CPT plugin without the design and the data on the front-end, he/she will contact the author of a new theme about this issue. The author will answer that he is not responsible for this plugin, so the buyer will contact the author of the old theme. This author will have somehow to find a solution or the buyer will have to delete this plugin. This situation will create a mess, both for buyers and theme authors. Another solution is of course to duplicate the code, in a plugin (as a fallback) and in a theme, but it will create a situation uncomfortable when we have to update the theme, more working time and there is a big chance that fallback design in a plugin will not match the new theme design.

I disagree, this is too complicated thinking.

It’s plain and simple:

Authors are not the only people who need to work with the given rules. If a person buys a theme with one or a set of plugins for that particulair theme, the buyers knows / or needs to know, that things like design for the plugin features won’t be the same or won’t we compatible when they switch to another theme. Simple as that.

How they want to fix it is up to them. They can contact one of the authors or another person for payed or free work – that’s up to the person they contact. No big deal further.

616 posts
  • Bought between 10 and 49 items
  • Exclusive Author
  • Has been a member for 3-4 years
  • Sold between 10 000 and 50 000 dollars
ChapterThemes says


But i already know that IF such option will be available one day, it would and should be irreversible: Removing item for everyone except existing buyers should be permanent
Why?

Well i figured Envato would like to keep some kind of stock control to make sure there won’t be suddenly whole disappearing pages with themes for example because everyone is working on a bug.

But i guess it depends on how every author sees it.

I know i won’t be hiding an item because of some minor bug. Specially if the item is still on page 1 till 5 or something, since you don’t want to waste those good places by hiding an item. Cuz before you know it the item is further down a few pages.

Maybe if a theme is at page 10 or 20 and it has an annoying bug i would hide the item to fix it. But not when it has good exposure.

616 posts
  • Bought between 10 and 49 items
  • Exclusive Author
  • Has been a member for 3-4 years
  • Sold between 10 000 and 50 000 dollars
ChapterThemes says

@Japh

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?

616 posts
  • Bought between 10 and 49 items
  • Exclusive Author
  • Has been a member for 3-4 years
  • Sold between 10 000 and 50 000 dollars
ChapterThemes says

I think it’s logical that you put the custom meta fields inside the same plugin that creates the custom post types. This way in another theme they can still use the custom fields in the other theme ( if they code it in that is ).

However, I digg the option of having the actual user-interface design etc. inside the theme. This way data creation is run by the plugin but the sweet interface that ‘makes’ your plugin would be gone but the data remains. A good way to protect plugin usage outside your own theme…

616 posts
  • Bought between 10 and 49 items
  • Exclusive Author
  • Has been a member for 3-4 years
  • Sold between 10 000 and 50 000 dollars
ChapterThemes says

Sounds like a good idea. Allthough the situation your sketching has some points of dicussion i think.

Because lets say you don’t want to sell a theme anymore because it’s hard to update – but you want to keep it updated for existing buyers.

If you can keep in updated for existing buyers, isn’t that the same as keep it updated for new buyers ?

I do know what you mean though.

But i already know that IF such option will be available one day, it would and should be irreversible: Removing item for everyone except existing buyers should be permanent

616 posts
  • Bought between 10 and 49 items
  • Exclusive Author
  • Has been a member for 3-4 years
  • Sold between 10 000 and 50 000 dollars
ChapterThemes says

I mostly use 940 or 960.

You could do bigger, but there a still lots of notebook / tablet devices in which this is a good width.

Not to forget not everyone is sitting in front of a 27 inch monitor.

I don’t know any stats, but a nice example of taking use of a bigger width i think is smashingmagazine.com .

But much call at the moment, i don’t think so.

616 posts
  • Bought between 10 and 49 items
  • Exclusive Author
  • Has been a member for 3-4 years
  • Sold between 10 000 and 50 000 dollars
ChapterThemes says

When updating WordPress of a site it has lost al the custom meta fields saved at posts and pages.

Anyone know how could this happen with a simple WP update from withing the dashboard ?

616 posts
  • Bought between 10 and 49 items
  • Exclusive Author
  • Has been a member for 3-4 years
  • Sold between 10 000 and 50 000 dollars
ChapterThemes says

I’ve discussed my ass off in the previous thread about these new requirements :)

But i just wanted to say thanks for the update and the new requirements are very clear to me!

Thank you!

by
by
by
by
by
by