Plugin will, basically, allow you to add Amazon products to your WordPress powered website. Here is a list of features that will be part of the first beta version:

• Search for Amazon products by keyword or by ASIN code and add them to database.
• Attach product to a post (post, page or any custom post types).
• Update products data periodically to get latest prices, info updates.
• Data classes for each product group supported by Amazon.
• Integration functions to display products in the theme templates.

Major problem with Amazon integration is the fact that they have many product groups, and each one has own set of attributes that are subject to constant changes, making it very hard to universally use taxonomies. But, database tables used for products will be flexible, and with wide selection of functions to perform all kinds of operations, we will try to make use of Amazon products as easy as possible.

If you have any suggestions on features for this plugin, please leave a comment. Beta versions of the plugin will be available for testing to all users with Dev4Press Plugins Bundle licenses. It will be available for testing through xScape.info also.

First plugin will be added in the next two weeks (and it’s a Pro version of one very important and very popular WordPress plugins). And after that one more developer will join, with 2 or 3 plugins. These plugins will be maintained by their authors, and they will be responsible for providing support for them. Also, these plugins will not be part of Dev4Press plugin bundle license.

There will be some changes on the website to prepare for third party plugins. So, stay tuned, more news on this will be available soon.

For a Weblog post and all the comments (including several I made) check out their post:

Trend for 210 – Paying for plugins: http://dv4p.com/hc

So, why should you pay for plugins? Or themes for that matter? For years most of the plugins (with very, very few exceptions) for WordPress were available for free. The same goes for themes, but about year and a half ago that changed, and several designers and developers decided to release so called premium themes and change for them. And during this year they modified their business model to include the GPL for the themes and practically shift focus to support for the themes. And from what I can see, that concept works great and more and more themes are in fact premium themes. And they are, no doubt about it, much, much better from the most free themes (with very few exceptions). Key word in all that is again support, and free themes are basically provided without any support at all (again with very few exceptions).

And, for the past year I use only premium themes, mostly from Woothemes or ElegenatThemes, and this site is made on the base of The Station theme from Woothemes. I don’t mind paying for quality, for fast support, after all all that takes time, and in the end that is not free.

In the past several months we have witnessed the same thing starting with plugins, with few developers started charging for their plugins. With launch of the WPPlugins website we got first payed plugins market. I am not going to talk much about WPPlugins website, but there are many things that are wrong with the way they work and is actually against my idea of how premium plugins should be provided to the end users.

Main reason I decided to start this new Dev4Press and launch several premium plugins is the fact that providing quality support for plugins takes a lot of time, and in the end I don’t have so much free time aside the freelance projects I work on.  It all started with GD Star Rating, and I really tried to provide as much help as I could with tutorials, documentation forums, and after all that users wanted more. So i tried to help on the individual basis by taking on some minor integration projects. And that was successful, but still idea is to have support that can be widely used. And after a while, I made several more plugins I provided for free, and they also have grown and again support became a problem.

So, I decided to stop with free support. If I can’t provided quality free support, than I will not do it, simple as that. And I expanded some of my plugins with additional features that will available only with Pro versions, even written one new plugin (Pro only), and I plan to dedicate most of my time to making WordPress plugins and provide the best quality support I can. Also, all plugins are available with few different packages that have different prices allowing users to find what is best for them.

And why the payed, or premium support is better solution? Imagine that you are building a site for a client (and you are payed to do it), and you are using a free plugin with free (and very limited) support. And, at one point, this plugin breaks down (no regular updated, or bug fixes). Your whole website is not in problems. You can try to replace it or fix it yourself, but that is not usually that easy. Best way is to contact author of the plugin and ask for support. In most cases even if you get response from the author, it will take maybe even weeks. And what you are going to say to your client: hey, this plugin broke, and I need to wait for the support, so we need to delay website for few weeks. Hell no! You will try to find someone to fix it as soon as possible, and you will pay a lot for that. It would be much cheaper if the plugin has premium support.

Just for fun, contact authors of each of the plugins you are using on your blocks (maybe 30 of them). I am sure than at least half of them will not respond at all. A third will respond after a week or two, and maybe 4-5 will respond sooner. But almost no one will be able to help you exactly when you need help. And that’s why is good to have premium plugins around, and give users a choice to pay for the quality. And labeling pluign as premium doesn’t mean that support will be any better, and that’s something all developers need to work on, to raise the quality and to justify the payments and really help their clients.

What you will get from Dev4Press if you decide to buy our plugins (and soon themese)? Regular updates, nightly builds and quick bug fixing releases, premium support forum, email support (development subscriptions), tutorials (both text and video) and extensive documentation. And on top of that, you will be able to influence the development using suggestions box and follow regularly updated roadmaps for all plugins. And be sure that I will release at least 3 new plugins in 2010, and two of them are already in the planning stages.

So, to summarize, paying for quality support is something that will definitively happen, and next year will be critical for this new business model for our beloved WordPress. Tell me what you think.

I made few changes to each of the WP installations so that the measuring rendering time is more accurate. Also, I changed few things in GD Press Tools also, and the Arthemia theme for the next part when the benchmark will be done for the actual blog. For some of the plugins I used older versions for WP 2.6.5, as recommended by the plugins authors. All results displayed on the charts are mean value from 5 measurements. I used Opera 9.64 browser for time and memory tests, and Firefox 3.0.11 with Firebug 1.3.3 for size of the output (personally I don’t like Firefox at all).

For test configuration and setup check the previous post: Benchmark Setup. On all 3 charts, first 3 columns for each page is for WordPress without plugins (only GD Press Tools is active), and the next 3 columns are for WordPress with all 15 plugins active, list of plugins in setup article.

Why benchmarking?

The reason I made these tests is because it’s obvious that no one in WordPress development team didn’t do anything like this. In fact they even claimed that WP 2.8 is much faster, and that’s simply not true at all. Take a look at this page, and notice that one of the highlights is speed of the admin pages. Speed can be gained using Turbo with Google Gears, and in that case browser needs less time to render the pages. But Opera, Safari, Chrome and Firefox are very fast already and will render very fast anything you throw on them. Browsers can’t speed up server response time. And Gears is not an option for Opera or Safari users (hopefully we will see better Gears browser support soon), not to mention problems I had with Gears in Firefox and that I don’t plan to start using it any time soon.

WP 2.6.5 is used only as a reference, in most cases you can’t really compare it with WP 2.7 or WP 2.8 because interface and some other things are rewritten, but it’s interesting to see how WP 2.6.5 compares to latest releases in terms of performance.

Page load times

First series of tests are to determine how much time PHP and server needs to generate a single page. Some of the things were problem to measure with WP 2.8, but I will get to that later. Even when the pages are partially loaded from cache this time is more or less the same. I noticed some 10-20% drop in WP 2.8 for reloading the same page, but that’s still too high.

WordPress load times

WP 2.8 is more than 2 times slower than previous two WordPress versions. On some pages difference is even bigger. I have measured 4 pages, 3 are WP native pages, last one is Settings panel from GD Press Tools, and it’s the fastest in the group because it doesn’t load a bunch of things most WP pages do.

But, there are some pages that need much more time. General settings page takes more than 10 or 15 seconds to load, because for some reason WP developers decided that the time zone list needs to be populated from WordPress website. This list could been included in the WordPress code. Right now it gets really frustrated to change any of these settings and need to wait all that time. That’s simple unacceptable.

Used memory

Things are pretty much the same with memory usage. As you can see 15 plugins add a lot to the memory used. WP 2.6.5 uses much less memory in both cases but that’s not a big surprise.

WordPress memory usage

WP 2.7 and WP 2.8 have totally rewritten interface and because of that it needs more memory. But the problem is with WP 2.8 that more or less should have the same memory usage as WP 2.7 because the changes were not that significant to cause this difference. Dashboard is the biggest problem and it uses some 25% more memory than WP 2.7. On some pages like the the general settings I mentioned earlier in some cases I noticed memory leaks and memory use increases to 45-55 MB. On one instance loading failed meaning that it exceeded preset 64MB. And again, that’s most likely caused by the timezone code.

WordPress output size

Page size

Finally this is something where WP 2.8 is actually better than WP 2.7. Again, WP 2.6.5 pages are smaller because of the different front end, but it’s interesting to see how much the interface ‘costs’.

WP 2.8 generates smaller pages compared to WP 2.7 mostly because of better optimization of JavaScript and CSS loading and joining several files into one. And in the same time that’s one of the reasons for slower loading and increased memory usage with WP 2.8.

Conclusion

There was a discussion on Weblogtoolscollection website about using 1 or 100 plugins, and it’s obvious that number of plugins active will increase used resources and time needed for page to be rendered. Another post that will investigate this much deeper. It will take some more time to prepare but it’s coming soon.

Based on all this is clear that in terms of speed and memory usage WP 2.6.5 administration is much better than the latest WP versions. On the other hand these are not actual pages that blog visitors see, and next post present results of blog benchmark under same condition, so I am not going to give some definitive judgement right now. I know a lot of people that still use WP 2.6.5 because they can’t increase memory every time WP is released. When WP 2.8.1 is released I will do a benchmark against current WP 2.8, to see if indeed developers managed to solve memory usage increase and lower speeds.

I use WP 2.8 on all my blogs right now, but I must say that I am not happy with performance of the administration compared to older versions. Interface IS much better, and to some point I understand and accept that the performance is a trade off for the interface and better work flow. But only to a point. I will be very disappointed to see WP 2.9 some 7-8 months down the road that instead of 40MB needs 50MB or more to work.

So, tell me what you think about data presented here, and about your own experiences with last 3 versions of WP, and especially with WP 2.8. And stay tuned for more benchmark results.