Our new Installer plugin is finally here, making it possible to install commercial themes and plugins easily from within the WordPress admin.
A long time ago, we started on an ambitious project, aimed at unifying the install and upgrade process of WordPress plugins. It’s ready and you’re very welcome to download and try it.
Our Vision – Discover and Install Commercial Themes and Plugins from the WordPress Admin
The idea behind Installer is to make commercial themes and plugins feel just like free ones from WordPress.org. We’re talking about being able to:
- Find
- Install
- Upgrade
I’ll be the first to admit that it’s a mess today. I’m admitting it, because we’re part of that mess. Paid themes and plugins cannot appear on the WordPress.org repository and enjoy its automation. We need to put our code on our own server and deliver it to paying customers. That’s how it is.
Unfortunately, this reality causes a mess to everyone involved. We have to spend considerable time hooking to the WordPress ‘plugins’ mechanism and getting it to know about WPML updates. We have to write code that goes in our server and in the plugin. That’s a lot of code to maintain.
You, our dear client, have to learn a new trick for every commercial theme or plugin that you buy. Since every author chooses to invent the wheel in a different way, each commercial piece of code has a different admin screen and handles updates a little differently.
Installer should change all of that. It hooks to the themes and plugins screens just once and opens them to different software sources. This way, wpml.org becomes a software source and other repositories will follow (we’re communicating with folks and working on that). Then, we can remove all that junk code from WPML. It’s not needed anymore. No more ‘subscription key’ or anything of that sort.
Our server, wpml.org, has started talking in the same language as WordPress.org talks. You will login to it from one admin screen, where you can (in the future), login to other software sources. Then, all upgrades appear normally in the ‘plugins’ screen.
Why we really like it:
- Lots of code gets removed from WPML
- A lot more functionality is added for installation and upgrades
- The stuff on WPML.org can be reused for different software sources
Installer Helps Theme and Plugin Authors
If you’re writing commercial themes or plugins, we warmly invite you to talk with us about using Installer. It’s made for you.
You can give your clients all the nice functionality of auto-install and upgrades, without having to write a single line of code to make it happen.
For Installer to work, your server will need to communicate using a standard protocol. We have reference code that you can use and we’ll help you adapt it for your subscription system.
If you’re hosting your work on a larger system, which you don’t fully control, let us know and we’ll talk with the admins of that system.
Download and Try
First, you should download and install Installer:
For now, the ‘old’ subscription mechanism is still available inside of WPML. Just ignore it. Installer overrides these hooks and the ‘subscription key’ will not matter anymore.
After you install and activate Installer, go to Installer->Repositories. You’ll see the new WPML repository. Enter your login to WPML.org. Don’t worry, we don’t save your password as plaintext. We ‘salt’ it and save it encrypted.
Once logged in, you can install and get updates automatically.
This is an excellent idea. It should be extended to major free plugins which are not on the WP repository for whatever reason, for example Cforms II and EZPZ OCB. Among premium theme frameworks I am a big fan of Weaver II Pro, and encourage you to approach them for inclusion.
We’re talking with major theme and plugin authors. As soon as we go out of beta and it’s standard for WPML, we’ll start helping them integrate it too.
Suggestion: wouldn’t be a first step making this plugin easy to find from the WP-admin in “New plugin” ?
Sure it is, but it’s not going to be on WPORG any time soon. They are not going to list plugins that open the WP search to other plugin and theme sources. For now, you’ll need to download it from wp-compatibility.com and then continue normally with other plugins. I know it’s not ideal, but that’s what we have at the moment.
By the way is this BETA or fully operational yet? I suppose you will notify us when the old way of updating will be obsolete and this plugin mandatory?
It’s fully operational, passed our testing and we’re using it ourselves. We’ll make this the default install method for WPML sometime soon. We thought it’s better to show it in beta and get feedback before we make it a standard part of WPML install and upgrade process. It’s easier to fix things now than when so many people use it.
Ok, thanks for the answer.
Do you want our feedback to be here on this page?
Here will be fine. Nikos, who’s developing this plugin will go over all comments here.
My first comment it that: all seems to work fine!
I wonder though why the Installer tab appears on the main menu on the left of the wp-admin page.
If you click on it, there are only Settings there, so why not placing it in the setting page? It’s making the admin unnecessarily heavier, and I expect in a daily use we won’t click on this tab very often.
I can’t help thinking that if everybody plugin developer was doing the same, it would soon be a mess in the wp-admin…
Just my opinion of course
I think it is a good idea and if works smoothly and do what it says, will be great. Will try in my installations.
A great idea…
Unification is always very important and makes things easier for everybody.
As a software engineer myself I know from experience that these ideas are great but often fail because of the lack of general support.
As you mentioned, off course already for WPML plugins such a general installer is a good thing, and if more orgs hop on the boat even better. Though, before announcing it as a unified installer it is normally always good to have other partners on board before announcing it that way. (A similar example is on other level (music prod. plugins) is the plugin alliance, which even creates a new standard)
The other point yo u guyzs have probably thought of is the fact that you will be responsible for the installer to work, other companies will lay back and it will need to work really good, and be handy for all parties, otherwise companies will hop off the boat again…
Lots of challenges you all have probably thought of, so I wish you lots of luck.
The idea itself is great, good cause, and definitively worth a try.
I will try it out myself on a customers webpage.
Best regards and my best wishes for this new project
Patrick
P.S: Thanks for such a god thought and usable multilanguage plugin as WPML!!!
We thought it would be better to first have it all running, live and for real, on our own site and with our own products, before we start offering this system to other vendors. We are talking with several and they’re interested, but it’s easier to launch on our own site first.
OK… Now I’ve got a very specific feedback out of the practical experience…
At least in my installation 3.4.1 the Installer plugin cannibalizes the Users Menu…
When I activate the Installer Plugin the Users Menu disappears and as soon as I deactivate Installer the Users Menu appears again…
Can anybody confirm that?
or is there a workaround?
cheers & regards
Thanks a lot for testing Installer and giving feedback.
You’re right. We placed our menu in the same position as the ‘Users’ menu and it’s hiding it. We’re fixing this and also moving our admin functions (as suggested here by several people), under the Settings menu.
Hi Amir
Great to hear that you are moving the item to the Settings menu. One question, because it is still unclear to me: you say you will release a fix soon, will the plugin self-update/propose me an update in the menu ? Or do I have to manually update it?
Thanks!
Very nice to make this happens. I made a shot with Installer on WP 3.4.1 / Wamp 2.2 / W7Pro.
Firstly, I agree with Emmanuel to be place the Installer tab under the Settings tab.
I tried the Check compatibility from Akismet and Hello Dolly and I got “There is no compatibility information for specified extension”, because I don’t have the auto-install/upgrade version, I suppose.
Also, I made a search in the “Install Themes” page with no-search terms to get all the results. I noticed a little visual aspect trouble, the check compatibility button for each theme preview is not integrated in the ul, it’s to close to “Details” button. And in the same “Install Themes” page when I click on “Search” ( top menu – Search, Search Result, Upload, Featured, … ) I got this warning:
Warning: Invalid argument supplied for foreach() in C:\wamp\www\wordpress\wp-content\plugins\installer\classes\api\wprc-themes-api.php on line 107
That’s it after a quick shot.
Thanks for reporting this. Nikos will check why it’s happening.
thanks for the proposal Amir,
it’s probably a great option, but my process include backup and test and sftp deploiement, so that don’t match with my process.
Please just maintain an updated list of compatible templates and plugins.
I am very opposed to running an additional plugin to facilitate plugin installation, this simply duplicates existing WP functionality.
You should look at the Gravity Forms from Rocket Genius, their method of update works great and is hassle free for the user. WordPress is perfectly configured to install plugins and themes as a zip file from the local machine with a simple click. Once the premium plugin is installed, even if it is out of date, their update system goes into effect.
I guess that I haven’t noticed the difference between the premium plugins and themes that I run and the regular repository ones except for the initial installation.
What am I missing, here, I don’t see any advantage besides the perceived marketing benefit for the authors?
GravityForms does exactly the same as WPML currently does. It duplicates the code in the standard WP plugins system and adjusts it to use their website. This is exactly the reason we’ve started this initiative, so that each commercial plugins doesn’t need to duplicate this code. It’s got to be duplicated, but not n times. One time is enough and different commercial plugins can use it.
My next thought is: Security
Does the burden of having the extra code outweigh the potential security risk of installing an additional plugin that gives access to a number of 3rd party developers who you may or may not have a plugin with.
Who monitors which developers have access to this plugin?
Who is responsible for updating and maintaining this installation managing plugin?
This solution seems to invite more issues then it solves… Although, I would be interested in hard data about the size and resource burden of the premium plugin update systems.
Again, I am a fan of the most simple & solid solution, and I need more convincing… I generally think that keeping the burden of all functionality directly on the developer who I am paying to develop the plugin keeps the project in his hands and it is in his or her best interest to make it work great without needing outside assistance. (or placing the blame on that outside assistance)
I am willing to pay for a premium plugin that offers a higher level of integration and experience over the many duplicate free options for that higher level, but also for the confidence in future proofing the website. Confidence in future reliability is why I use WPML over Qtranslate in the first place, allowing the developer to place that blame somewhere else starts to compromise that.
Security is a critical issue here.
1. The same developers who work on WPML, also work on this plugin. We’re doing security audits for every plugin and this is no exception. The good news is that we’re getting better at it. Each plugin that we send for external security audit comes back with fewer comments and lower severity. We’re actually learning from this process and writing more secure code to begin with.
2. Since we’re treating it now as its own projects, it’s on the spotlight for everything. This includes features, stability and security. Can you really say that you considered the security of the current upgrade logic in WPML? Now that it’s a plugin by itself, it’s a topic for discussion. This is good for security.
3. Soon, more authors will be using Installer as their install and upgrade system. Not too many WordPress shops have our resources. We can provide solid, reliable and secure code for this function. From experience, I can tell you that a lot of code you see isn’t robust or secure enough. Having others use our code will mean fewer overall issues in your site.
We’re not passing the ball here to anyone. The Installer plugin is our sole responsibility. Instead of maintaining this code as a block inside WPML, Types and Views, we now maintain it as its own product. Believe me, this makes the product a lot stronger. Instead of having the installation process an unfortunate chore for someone, it’s become the pride and joy of a very talented developer on our team.
So, I sort of see the advantages for you, the developer. Although I may not see how that’s going to ensure you work closely with other developers to gain that same level of integration and security unless you are charging them for the service…
But, does this really make my life as the consumer of your product easier / better? That’s what you need to convince me of. Especially since I have never had a problem with the current system.
This is the same situation that I face as a WP developer. I need to convince my clients that they should pay me to make sure that their WP site is kept up to date and that proper backups and security measures are taken at their cost to ensure any downtime is kept to an absolute minimum.
As a consumer, your benefits will be:
* Smaller, and faster site – overall. By removing this duplicate from several places, you’re making things more efficient.
* More solid code – today, you might be using unmaintained code for plugin and theme updates. We see this in many places, where people wrote something a long time ago and don’t properly maintain it over time. It’s because this is not their focus.
* Faster install and upgrade process – soon, you’ll be able to use this Installer plugin for different themes and plugins that just don’t have any automated install process today. Many small development houses don’t have the resources to deal with this. They are waiting for our solution, to use without investing that time.
I hope that help. Still, it’s optional. If you don’t like this new Installer system, you can keep installing commercial themes and plugins manually. It’s all up to you.
I agree this is a good idea. I hope it will be adopted by other commercial plugins/themes developers.
I see themefuse.com has something similar, but as proprietary solution. I also know several developers that will find your solution, in case it works as supposed to, a great chance for improvement.
Totally agree with RS!
I would prefer to have total control and manually update my plugins (via WordPress or SFTP) and themes – If I still have the option to do that – great! – If not, I would like a refund as this was NOT part of the deal when I paid for the WPML plugin’s.
This Installer plugin doesn’t change your options. You can still install plugins manually either by uploading a ZIP file or by uploading the files via FTP.
The only change is that we moved a function from our plugins and put it in a separate plugin. Today, WPML is already split into a family of plugins. You have the core WPML plugin, String Translation, Translation management, CMS nav and others. Instead of repeating the same upgrade functionality in each of these plugins, we thought it would be a lot more efficient (for you), to have it in just one plugin.
If you prefer to update plugins manually, you can still do that without any change. In that case, you don’t need this Install plugin at all. Does this answer it?
Thanks for the quick response!
Yes, you have answered and I feel much better knowing I still have total control.
Just for the record, automated upgrades are not for everyone on every site. For example, on wpml.org, we don’t ever use automated theme and plugin upgrades.
Because we run a pretty busy site, and down-time is very expensive to us, we don’t just “upgrade” plugins at random. We have a development site where we test everything. Then, when we’re ready to go live on the production site, we backup the file-system and database. Then, we upgrade all at once.
So, we understand that different people have different needs. We are really trying to help here, make things more efficient and easier to web-masters to maintain sites. We’re open to ideas and have no intention on forcing our opinion on anyone.
Will the new installer be compatible with VCS/DVCS installations? – where the upgrade is done on development-installations and production is updated from SVN, Git, Mercurial, … will WPML still check the current state of the database and migrate it if necessary?
Can you give me a link where these installations are described?
There is no need for a description per se … just imagine a company or professional service company implementing complex WordPress solutions for customers … REAL developers so to say, not just Joe Average building a small site for his Mom’s business ;-). An Environment where e.g. 5 developers working on their own development environments using SVN and Git, a staging environment where customers can review upcoming features/releases and finally the production environment/site where things are deployed. In that case developers update plugins in their local environment, commit changes to SVN/Git and production/staging gets checkouts/deployments via SVN/Git. Many professional and commercial plugins, like GravityForms, Shareaholic, W3 Total Cache and the current WPML suite (inc/upgrade.php), for example, track the “version” of their database state in a WordPress option and run migrations each time the version differs from the one the plugin needs, using dbDelta() for example. Bad plugin developers hook potential database updates into the plugin update hook … which is never fired in such environments.
Right now, WPML works perfectly in such environments (as mentioned above), the question is, will the new installer too?
Yes. The new Installer will let everything work exactly as before. The only difference is that all WPML components will use it from one place, without the same functionality duplicated in all WPML parts.
A great improvement to the WPML process!
Just one general comment. If you are looking at the WPML apps, for those not installed, it gives the impression you must ‘Buy ($79 USD)’ – which is of course wrong, as they were included with the purchase, just not installed!
Pretty minor, but I could see someone posting a frustrated “WTF?!?!” regarding it…
Cheers!
Chris
If you already purchased and you’re logged in, you’re still going to see the price, but also the ‘download’ URL. We actually debated quite a lot about how to present the cost of the different addons. I’m still not sure what the best way is. Anyway, you cannot purchase WPML twice – not even by mistake. After you buy it, our system will see your name and email and will not let you order again by mistake.
“I’ll be the first to admin that it’s a mess today. I’m admitting it, because we’re part of that mess.” – a little sneaky typo 🙂
Thanks. Fixed that typo.
I’m also opposed to this – having to install a separate plugin just to update a single plugin is a lot of extra work with seemingly no benefit.
I realize it’s a chick & egg problem, but I’d urge you to keep the old update mechanism around for the foreseeable future until (and if) the installer plugin has been adopted more widely and actually offers a benefit.
I for one didn’t pay for WPML only to be forced to install another plugin that itself will need to be maintained.
Right now, using the Installer plugin will save considerable memory from your site. Instead of having that code replicated in all our plugins, you will have it in just one place. The intention was really to make things more efficient and easier – not harder.
We need to maintain this functionality anyway. It’s a lot easier for us to maintain the installation logic in a central place, than have that code repeated in the different plugins.
But anyway, if you don’t want to use that plugin, you don’t have to. You can always upload ZIP files to WordPress. This hasn’t changed.
But I only use one of your plugins – I do understand the logic of doing it from your perspective, I’m just trying to explain why it’s more work for a regular user who only has a single plugin of yours.
Good to hear you are working on making it easier to install and update the WPML plugin.
I think it would be even better if WordPress.org offered some sort of payment mechanism like they do for commercial themes on WordPress.com.
We’ll get to that too, but I don’t want to make noise for nothing right now. Everyone is busy (including the folks running WPORG). When we have something good to offer them, we’ll have a friendly talk about that.
These are realy pretty bad news:
1. On an current project this installer breaks the complete website (!) cause the server-firefall blocks requests to 74.50.62.71 (http://wp-compatibility.com/) – only manual Plugin-Uploads via FTP are possible here.
2. As you see this makes WPML also unusable for intranet solutions and so on.
Pretty bad and anoing that even already existing projects matching one of the points above won’t be able to be updated in the future.
I hope you rethink this step!
If you’re on a local Intranet with no web access, you cannot use WPML’s automatic updates anyway today, because this will require access to wpml.org. Right?
So, since you cannot use automated plugin updates, this Installer plugin is not for you. You have no need for it and it’s not going to work in your environment. I’m assuming that you’re updating plugins manually. This doesn’t change. You can keep doing that just fine.
Am I missing anything?
So you will provide manual downloads in the future? That’s fine! 🙂
Sure. The ‘downloads’ page in wpml.org will remain the same. This is just a technical change, which moves the automatic upgrade from WPML code (the plugin) to a separate plugin. Everything works as before, including manual ZIP-file downloads.
This is a great idea. However:
(1) The installer plugin seems to spawn endless identical cron jobs. That’s a bug that needs looking at.
(2) I’m afraid I don’t like the UI with the dropdown menus on the install plugin page. It’s a clever idea (check boxes in a dropdown) but it looks ugly.
(3) When I tried to login from the search plugins page I got “unknown error”, although it appeared to have saved.
(4) I have no idea of the purpose of “Check Compatibility”.
I actually agree with all Marks’ opinions
Like Emmanuel I am pretty agree with all Mark’s opinions.
The bug with these endless cron jobs kill my client website all this weekend.
Is you disable the Installer plugin, wouldn’t these cron jobs stop?
Hi
I’ ve been exploring a bit more and realized that in the plugins tabs there was also this new item called “check compatibility”
When clikcing on it, it seems to give some compatibility tab compared with other plugins…
I have to say it looked powerful on one side, but also it got me puzzled… I don’t understand the table itself very well, its randomness (some plugins have info, some other not), its completeness/incompleteness.
What I do understand now is that using the domain name wp-compatibility.com to host the installer DOES seem to have a reason, but a reason understood by few lucky ones… well I’ m not among them.
Amir, I think I’ve expressed in the previous weeks how AMAZED I was by the power of the applications you guys are developping. It’s simply brilliant, you’re a pilar of wordress now, no other solution is as complete as yours, and I am a happy and thankful customer, really. But I’ve also sent many remarks to Icanlocalize giving my feedback experience concerning the UI. It’s often messy, confusing, unclear. It’s quite a bullfight the first time you open this thing.
So, if you accept my humble opinion of a lamda user, your installer seems to repeat the mistakes from the past: some powerful lines of codes, probably useful to thousands of users and developers, but hidden in a sort of blizzard where it’s unclear who does it, who needs it, why it’s called A but hosted on B, why there is this option C that is explained nowhere but has a similar name as A…
I still don’t even know whether the updates of installer will be pushed to me or if I have to fetch them manually on wp-compatibility website? Note that the website mentions no version, so I don’t know either whether my version is the last one or not…
Please please please, keep it simple, and clear!
(all this said IMHO of course, some other people might think differently)
The compatibility info is being populated right now. It’s still all in beta and data is very far from complete. We’ll have a lot more information soon. As there’s not much real data yet, we didn’t complete the visual design for the compatibility results. We’re doing that next.
When there’s meaningful data, we’ll also have a nice version that shows it sensibly. We got a ton of valuable feedback from this first release and are going to release an update that addresses all these issues. At that time, we also believe that many people will be looking for our Installer plugin, to see compatibility status between themes and plugins that they’re interested in. So, we launched the site as wp-compatibility.com. We’ll have lots more to show in the coming weeks.
Ok, curious to see what comes next. Thanks!
PS: you still haven’t answered my question, will the update of the installer be pushed to me or I have to monitor your website for an update? Thanks a lot!
Sorry, I missed your 2nd question. Yes, we’ve set up a repository on wp-compatibility.com and this update will come via the WordPress plugins page. You should see it shortly, as WordPress caches plugin updates for 1-2 days.
Hi Amir, thanks for your answer, that’s good news.
Already received the update and it’s nice too see some of the changes we talked about already. Long life to installer!
It´s great but… Installer crashes all pages of one of the three languages of my site.. Give this kind of message :
Fatal error: Allowed memory size of 103809024 bytes exhausted (tried to allocate 1421729 bytes) in /nfs/c09/h02/mnt/137511/domains/(XXXXX)/html/wp-includes/functions.php on line 316
Deactivating it everything is back to normal. I can send you the link & logins via email (it´s a dev playground).
Obviously, this isn’t supposed to be happening. I’ve passed your details to Nikos (the developer for Installer), who will contact you privately.
I have installed installer but as described on the website I do not get the “Login” feature for my WPML plugins and I have had to continue to update manually. Compatibility is working fine I must say 🙂 Keep up the good work and good ideas!
Nikos is contacting you privately (via email), to get debug information from you. Please respond that that email, so that we can nail the problem your account is having. Thanks!
While following your instructions to install the Installer program prior to WPML, my site has now crashed completely! I followed your step-by-step instructions on this page http://wp-compatibility.com/installer-plugin/ and when clicking the Activate plugin link, the site disappeared! I tried it in 4 different browsers with debugging on so I could locate the error but all I get is the HTTP Error 500 (Internal Server Error): An unexpected condition was encountered while the server was attempting to fulfill the request. It’s gone – no more http://israpay.com! Need your help ASAP!
I’m writing an email to connect you with the developer of the Installer plugin. We’ll see what’s happening there.
Would love to have an automatic update that works. I’ve tried installer a few times over the year, but have always had to delete it via FTP, as it would make my site inaccessible. So, same prog as Moshe.
Waiting in anticipation for a working solution.
I’m sure that we can get Installer working for you. It’s running on over 20,000 sites now without problems. I’ve sent your details to Ignacio, the developer of Installer, to check what’s happening. He should be in contact soon to get more information from you.
Same here for the automatic updates not working. Has this been addressed yet?