This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.
Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.
No supporters are available to work today on Toolset forum. Feel free to create tickets and we will handle it as soon as we are online. Thank you for your understanding.
|-||10:00 – 19:00||10:00 – 19:00||10:00 – 19:00||10:00 – 19:00||10:00 – 19:00||-|
Supporter timezone: Europe/Madrid (GMT+01:00)
Now when the new Embedded Toolset plug-ins came out it is really easy to distribute themes and theme updates. However, I do have some very serious questions/ concerns regarding distribution and licensing policy. Please help me to solve them.
Many of my clients will consider the new distribution schema as a very strong vendor lock-in. In order for the theme to function they have to run several plug-ins that will require a subscription
just to keep the theme running. This alone, not mentioning the fact the many clients would hate to install additional plug-ins for the theme, would repulse them. "Why not to put code to the theme itself?", would they ask, and probably be right.
To keep thing going they have either to buy a subscription or rely on me that I will provide them a valid key for as long as they would like. Both options would not be seen as very reliable by them.
I do not imagine many of them purchasing a Toolset for $149/ $229 just for this theme when there are so many good premium themes that would cost $20-$100 and have many customization options. Moreover, Toolset is a developer tool. It requires CSS/ HTML knowledge. It is good for us, developers, because we can implement everything we want, but many customers would not have such knowledge and would prefer visual tools with color pickers and stuff. So it is probably not for the end-users, at least right now.
Many clients are not tech-savvy enough to do the changes they want and would prefer to hire a developer. However, any PHP developer will not do because he/ she will need at least a Toolset license in order to do anything. That perspective would certainly make my clients very unhappy. And that's why they would probably never choose Toolset for the new development unless on some rare occasions.
Another issue is that without Toolset subscription/ Toolset developer they will not be able to do even a simple task of changing a text on a button in a view or in a form. For this they either have to buy full Toolset subscription or pay $$ to the developer. Not very good to them.
Competition is very tough, and clients are well aware that there are many customizable themes and visual page builders.
Toolset is positioned as a tool for developers. As a developer, I would like to produce one solid piece of code that I will ship to the client and that will simply work without any other prerequisites. And this is what my clients expect for me. Ideally, I would like to have an ability to have Toolset installed on my computer, create a theme or a plug-in with it, and export everything into a PHP code. Clients expect this from me too. They expect my code to work without any additional premium subscription/ services. And they would love to have a chance to do a simple tweak in a PHP code themselves here and there if there is need for it.
As an option there might be a button somewhere on the theme options page that may offer customers to buy a subscription and edit the theme themselves (though they will not be able to if the theme is heavily customized with custom callbacks and other stuff).
If templates are stored in the database as they are now, on my opinion it would be nice to give customers an ability to change text on the elements that are already created for no fee. Let them not be able create any new elements, but to pay $149 just to change a text on a button would sound like a nonsense to them.
Maybe I understand market wrong, but I do have a pretty good experience with many clients, with my market niche (probably low to mid end). Competition is pretty tough, so I have to offer some good value for the money. Toolset offered me an ability to create things fast but this new licensing schema may kill all advantages.
Where are you planing to move? What your target market is going to be? Will you keep the old way of embedding thing to the theme without plug-ins or will it be replaced with the Embedded Toolset plug-ins completely? Will there be a way to export code to PHP if customer will decide to keep development without Toolset (not many probably will but this option provides a great feeling of safety)? I am a loyal Toolset owner from 2012 and I would like to know whether I will stay competitive enough to sell my work with it or will I be forced to search for other options (which I would really hate to do)?
It's may be TL, but hope you not DR :-). The topic is really important to me because Toolset is an important component of my workflow.
Your customers would receive the embedded versions of our plugins that are free.
They would only require to purchase a license if they want to make changes to the Toolset components.
In any case I have forwarded your concerns to the appropriate person.
Thanks for your opinion
Kirill, your feedback is very important to us. We released this version of Embedded Toolset early, so that we could get this sort of feedback.
Let me explain our goals:
* We want Embedded Toolset to be appealing both to the developer (you) and to your end-user.
* We don't believe that we would get Toolset sales from your end user. Like you explained, your end-users have no desire to become experts in Toolset. They require a complete solution for their sites when they buy a theme.
* We realize that the theme market is competitive. Our goal is to provide a solution that has big benefits to everyone involved, not only to us.
* We hope that the exposure that Toolset-based themes will produce (if done right) would encourage more developers to buy it from us. But not in order to customize these themes, but to build sites based on Toolset themselves.
So, our goals are completely aligned with your. This is why we appreciate your feedback very much.
The reason we decided to take Toolset out of the theme code is due to the hassle of upgrades. You are probably aware of the recent wave of panic security updates to WordPress itself, themes and plugins. Imagine the hassle that you will have if you include plugins in your theme and these plugins have frequent bug-fix, compatibility or security updates. Instead of developing themes, you would only work on panic updates, testing and releases.
The new scheme for including Embedded Toolset takes you out of this look. Your end-users always receive the most recent versions from us. As soon as there are updates, they receive them directly and automatically.
Your end users don't need to buy anything from us to receive Embedded Toolset. As long as your Toolset account is valid, the theme delivers these updates automatically. The Lifetime Toolset account provides this option. You have this account, so any theme that you build now with Embedded Toolset will deliver updates to your clients always.
Back to customization...
Your note makes sense and we've been thinking about this too, since we started building test themes with Embedded Toolset too. We quickly saw that not having access to editing texts is a deal breaker. We decided to push this first release anyway, so that we receive real feedback from real theme developers (like yourself).
I think that we should change the mix of features in the Embedded versions. They will include all the editors, but without the option to create new elements. This will go great together with a wizard that we are planning to add to Views. This wizard will let you create new Views, Content Templates and WP Archives more easily. The Embedded version will just not have that wizard.
There is a still a question about colorpickers, font selectors, etc. I think that this is best left to the theme, in the Theme Customizer in WordPress. We are going to include complete integration with this in Views, so that you can push settings from the Customizer into Views code.
Does this make sense?
Thank you for going into such great details explaining your company's position to me. This is extremely valuable and I appreciate this a lot!
I think your reasoning about having an Embedded Toolset as a plug-in totally makes sense. Having it updated automatically will greatly increase security and will guarantee that the theme will (most likely) work with any future version of WordPress.
However, it is still not clear why would it require a valid Toolset subscription in order to receive updates. Is it to make developers value a lifetime subscription more? I think the mere fact that they will get access to the new features, bugfixes, support and compatibility with future WordPress versions would be convincing enough for them to extend their subscription.
My concerns are that my customers would feel that I might, if they decide to hire another developer to replace me, cancel their Toolset key as a “punishment?? and they will be left with nothing. I would never ever do that but my new clients do not know me well and words sometimes are not convincing enough. All they want is that their theme will continue to work no matter will my subscription be valid or not. They don't want to depend on me and I understand it.
Is that possible to make Embedded Toolset completely free, without any requirements of a key activation? In addition to the reason described above the other inconvenience might be that activation key is tied to a domain name and if my client would change it (not often, but might happen) and he/she cannot reach me to update the key (which is not very convenient for them on itself) they will be stuck.
My clients want to be sure they will always receive their updates no matter what. If activation key is a must-have feature, may there be some possibility that they will be able to get their own personal key just to receive Embedded Toolset updates if anything will happen with their developer (will stop answering email/ disappear/ etc.)? But this still be worse for them than no key at all.
Regarding ability to make small changes without having a full set of Toolset plug-ins it is very comforting to know that you have this in your plans and are probably working on this already. I believe it will be very important for the end user. Not everybody will necessarily do any changes, but there must be an option for that. Actually, this could be a good selling point that the client, without any knowledge of PHP, will be able to fine-tune their theme.
It is often the end user has the last word on what technology to use for their site (they do not know every little detail but they might've heard something and most of all they want their sites to be easily maintainable), so we should convince them as well. Sometimes it is hard, but I believe Toolset is a great package and well deserves appreciation of both developer and their clients.
Maybe you should have a page or two on your site just for developer's clients to explain what your technology would bring to them specifically? They would have less questions why it is important to have part of the theme as a plug-in and why it is actually better for them. May be you can even (a little crazy idea) build in some additional service functionality for the Toolset or for the site so that the Embedded Toolset plug-in will create an additional value for them (an unexpected extra)? This probably wouldn't be too hard as you probably have something like this already. Then they would treat it more as an asset and not as an obligation.
Thank you again for your great support!
The reason we decided to connect distribution for Embedded Toolset with a valid account, is that (we think) you would also need ongoing support.
Realistically, when you develop Toolset-based themes, you develop with the full plugin versions and then you distribute themes that auto-install the Embedded versions.
So, you need a valid account anyway, to continue your development.
I don't want to encourage developers to develop and abandon. If their subscription runs out and they still develop themes based on our plugins, who gives the support to the end users?
We want to make sure that as long as these themes are distributed and end-clients use them, there is an active developer maintaining. So, by requiring the developer to have an active account, we think that we increase the likelihood that this develop will be actively working on his Toolset-based themes.
I don't know if this will really happen, but that's our goal.
Our sales and upgrade stats show us that most people who originally bought a yearly account upgrade to a Lifetime account before the first year ends. This was the case before we started offering the Embedded Toolset. So, we're not trying to pressure anyone to do anything. We want to avoid a situation where a developer gets excited, creates a theme and then walks away. This would make everyone look bad, including us, because there will be dead themes that feature our plugins.
Your suggestion about making documentation for end users makes perfect sense. I'm adding this to our todo list. We'll include the editors in the Embedded Version and then create documentation that explains to end users how to easily add Toolset-based elements.
Since we're going to change (a lot) the current mix, I prefer to wait with this documentation.
I really appreciate your desire to guarantee that the theme will have constant support. I think it is very important for the end user. However, with life being life as it is, there is no reliable way to make all developers behave responsibly. If the developer will get tired of the client, or the client will decide to get rid of the developer, support will be broken anyway. And that might happen in a real life. There is no way to force developer to work with the client if he does not want to and vice versa. So there should be the way to handle a change of developer. The only thing you could do here to support customers, on my opinion, is help them find a new developer or provide support on your own (and not necessarily for free).
The question what will happen with the license key if developer leaves the project remains unsolved. Because it is the developer who supplies the key, the customer still depends on the developer he has no business relationship with from now on. I feel this is wrong and may be a source of potential problems. There should be some way to solve this for the customer.
From how the customer will appreciate the Toolset will depend both my sales and your sales (as more developers will be buying Toolset seeing commercial potential in it). We have common goals here. Let's find the best solution that will make customers, and developers, happy.
Really appreciate your honesty and support. This is invaluable!
It looks like I was probably wrong that Embedded Toolset keys are tied to a domain name. For whatever reason I was thinking that it works the same way as Full Toolset keys do, where one has to specify domain names on what Tollset key is active. However, it seems that for Embedded Toolset the key is created for the theme name, not for the domain. Does this mean that the Embedded Toolset key is valid for any number of installation of a theme with any given name?
Yes. The theme author generates the key once for the theme and that's it. End-users don't need to generate anything, enter anything or create any account with us.