WooCommerce 3.0 Brings Major Improvements to Product Gallery, Introduces CRUD Classes and a New CLI

WooCommerce 3.0 “Bionic Butterfly” was released today with significant improvements to the product gallery and developer tools. This version, which was previously going to be 2.7, is the first major release since the plugin switched to semantic versioning. It was released after more than three months in beta and an extended RC testing period that allowed extension and theme developers enough time to get up to speed.

The new product gallery has subtle improvements for galleries with multiple images. Clicking on a thumbnail updates the image without forcing it to open in a popup window. Galleries in 3.0 are also more intuitive on mobile with support for touch gestures, including swipe to scroll through the gallery, pinch to zoom, and swipe up to close the current image. These and several bug fixes and improvements deliver a much smoother experience of viewing product images.

This release includes significant performance improvements, thanks to the switch from post meta to taxonomies for features like product visibility, featured products, and out of stock products. WooCommerce contributors have also reduced the number of queries required to display related products and upsells.

Version 3.0 introduces CRUD (Create, Read, Update, Delete) classes for developers, making it easier to write and retrieve data from the database with less code.

“High order volume is one of the best problems a store can have, but it can really slow down your site’s performance,” WooCommerce lead developer Mike Jolley said. “That’s why our team’s main focus this year is performance and scalability.” Scalability improvements are planned for the next several releases.

Version 3.0 also introduces a new command line interface (CLI) powered by the REST API. The previous CLI didn’t fully support the same functionality and was powered by its own separate code. The new CLI forks Restful to make REST API endpoints available as WP-CLI commands. It reduces the amount of code that WooCommerce has to maintain and ensures that the commands are always current as the project’s REST API is updated in the future.

The WooCommerce support forums on WordPress.org have been lighting up with requests after 3.0 was released. One particular issue pinned to the top of the forums is an incompatibility with Select2 v3. The latest version of WooCommerce uses Select2 V4 and this may cause an issue with AJAX search inputs in plugins and themes loading an older version of Select2.

Another issue users are having after upgrade is frontend pages reloading endlessly, which WooCommerce developers have identified as a problem with the geolocation setting. They are working on a fix for 3.0.1.

Many users who are reporting issues after updating to 3.0 have discovered incompatibilities with themes or plugins. This release received more than 3,000 commits from 115 contributors. With this many changes packed into a major release, WooCommerce developers recommend testing on a staging site and making a backup before updating the plugin. This will give you the opportunity to make sure your theme and plugins are compatible with the update.

57

57 responses to “WooCommerce 3.0 Brings Major Improvements to Product Gallery, Introduces CRUD Classes and a New CLI”

  1. The least users should do, is download their current version of WooCommerce from their website before they update because if there are problems, they will have difficulty finding a previous version.
    An issue brought to you by the All New Plugin Repository design.

    • That will actually not be enough, as most likely the new version will change the DB in an incompatible way, so full backup ( as always) is needed.

      Anyway, people that don’t keep the software they use in git/svn and rely on getting older version from 3rd parties, deserve all the pain they get.

      • Anyway, people that don’t keep the software they use in git/svn … deserve all the pain they get.

        How much nonsense is that?

        Joe and Jane, the average users and – mind you – comprising probably more than 80% of all WP users, don’t even know thew words git or svn, let alone their meaning!

        • @wayne, and your point is? People that contract site development need to understand the basic needs of such an enterprise, and if they don’t, the developer needs to explain to them.

          When people buy a car, they know that the car should include engine, brakes, and it needs to be serviced for oil water etc. Well, they don’t have to know all those things to just buy a car, but they will get much more for their money if they do.

          Same with sites, some basic things like backup of code and data are…. basic. You can have a site without them but it is like driving car without ever paying attention to the status of the oil.

      • Anyway, people that don’t keep the software they use in git/svn … deserve all the pain they get.

        Oh really?

        Joe and Jane, the average users and – mind you – comprising probably more than 80% of all WP users, don’t even know thew words git or svn, let alone their meaning!

        • Well, if they don’t know how did they build the site? did they learn PHP and JS at the evenings? Oh they hired a developer…. and the developer also don’t know how to open a free account on bitbucket or gitlab? what kind of a developer is (s)he ?

      • @Mark K, I won’t publish what I think of your pompous remark. As both Wayne and Susie astutely pointed out, most have no idea what comprises a git repository – which is almost exclusively the domain of experienced developers.

        We have a large customer base, and I would be surprised to find 5 users in that base who have any familiarity with Git.

        @M I agree with you that the new design leaves a lot to be desired. As Neo below advises (and I think a couple of others) one has to use the Advanced function in order to get the prior builds to display. Really not intuitive.

      • Come on Mark, even me, a dev, I don’t use git nor svn on live sites and you want an average user to be able to set that up ?

        Anyway, this issue has been mitigated with the new Advanced page which shows both the stats and the older versions.

        As for the DB backup, it’s true that it should be more common practise but we are not there yet.

        I think, the best way to mitigate all of this and more is to switch away from traditional hosting to VPS and Cloud hosting in order to have access to Full Server Backups and Snapshots but we are not there yet too.

        My initial comment up there was more geared towards the average end user and owner of a website. Now, if you are a business whose survival or reputation heavily depends on your website, then of course, it’s your fault for not learning or hiring someone who knows and practises failsafe updates and processes.

        Finally, I wanted to stress out that the bugs and incompatibilty issues are not entirely WooCommerce’s fault since any dev developing add-ons for it should, from time to time, visit their dev blog or their Github account to stay on top of things and upcoming developements. And in this particular case, WC extended the beta period and even changed its versioning policy to stress out the important evolution of the software.

        • @M, well, you should start to use git. If it is actually on the live site or just an off site repository it doesn’t matter, the important thing is that there is some history of your code that will help you remember why everything is like it is when you will need to do some extra work next year.

          But the issue is not mitigated by being able to upload an old version…. big chages like this usually include changes in the DB structure, and the old version will probably not be able to work with them. This is why a backup is essential, and setting up a proper testing enviroment is even better.

      • Actually, an automatic backup functionality with a full restore option (both the files and db) should be shipped with WordPress as a standard! I can’t understand why it’s not there. Why the heck we need to install backup and security plugins??? It’s like buying a car without fuel gauge and door locks, only to have them installed in a garage minutes after you drive out from the car dealer.

      • Furthermore, and jumping on the “Joe and Jane” bandwagon, far from understanding git & svn, Joe and Jane the store owner are presumably users rather than developers.

        As users, I expect they care most about experience – *their* experience and their users’s experience more than they’ll ever live, breath, and bleed code.

        I think the big 3.0 update, while it brings awesome steps forward, also highlights how WooCommerce is not “seamless” the way hosted solutions are.

        Against that backdrop, if you are a WooCommerce Store Owner – how do you know if you’re doing everything you should? (BEFORE it’s too late!)

        Well, at the risk of some shameless self promotion, I put together this “Woo Store Check Up” to help WooCommerce store owners identify:

        – what they are doing well already
        – what they should improve
        – what they might be missing

        No sales pitch. The checkup is free. And so is the 7-part DIY email series.

        https://woobetter.com/check-up/

        Here’s to helping every WooCommerce store owner sleep like a puppy.

        Cheers

    • WooCommerce devs are currently directing users having problems with 3.0 to their GitHub account so they are able to download previous versions of the plugin. I foresee similar situations for many other plugins, which is a bit sad.

      • This is really unfortunate, I agree, but I (and the rest of the WooCommerce team) also go to great lengths to stress the need to make backups (and possibly use a staging server) before you update, so you can instantly roll back to a working site.

        We’re directing people who have already hit the switch and have no way of rolling back to those previous versions, no doubt, but if they have no backup there is not much else we can do.

        I would absolutely love it if we could launch without issues every time — it’d be less work for everyone, from our customers to our developers to our support team — but the open source nature of WP/Woo means there will be conflicts, and that we’ll be finding whatever way we can to resolve them. Even if that means linking to Github and saying “we don’t want you to lose money, so please roll back to this version for now while we look for a fix.”

    • You can download previous releases from the WP repo, go to the Advanced Views in the sidebar, then at the bottom of the Advanced page, you will find a section called Previous Versions, then use the dropdown to select which release you need to download.

  2. The reason many theme and plugin developers have not updated their Select2 script is that the newest versions of Select2 removed very important sorting abilities. I and other developers have been asking the Select2 team for months about this, and they have not been responsive at all, in fact they don’t even seem to understand the issue of the removed sorting options. So none of us updated (we could not advance past ver 3.4.8), as if we did you the end user lost functionality, and since when has an end user ever been happy about that?

    As for Woo’s wonderful position that they allowed developers time to get up to speed – it must have been all the free theme developers who contribute to the themes at wordpress.com and the wordpress codex – I am part of a development team that has sold closing in on 100,000 theme licenses, and friends with dozens of other theme and plugin developers and we are all gobsmacked by this. But its not the first time for any product associated with wordpress and automatic, and I don’t suppose it will be the last…..

  3. so here it goes again how the “always upgrade” fails real users with real sites…. and still instead of “everyone should have staging/testing enviroment” message, maybe with core adding some functionality to make it easier, we hear about it only **after** upgrade ruins people’s site.

    Yoast first, now WC…. isn’t it enough of a prof that even top developers should not be expected to release bug free version that will work in all the possible scenarios in which wordpress is used?

  4. Woocommerce is not working at all after updating. Shop page is gone and it is no longer possible to proceed with the checkout/payment, just keeps loading forever.

    Warning: Declaration of WC_QuickPay_Order::get_transaction_id() should be compatible with WC_Order::get_transaction_id($context = ‘view’) in /var/www/outdooricentrum.dk/public_html/wp-content/plugins/woocommerce-quickpay/classes/woocommerce-quickpay-order.php on line 12

    WHAT NOW??

    • You are experiencing a commonly reported problem. Your best bet is to upload the prior version of woocommerce by ftp, but you need to do it correctly.

      Unpack Woo ver 2.6.14 on your desktop. Rename the folder to say “woocommerce-new”. Now upload that to your plugin folder by ftp so that you have both a woocommerce folder and the woocommerce-new folder. While still in ftp rename the woocommerce folder (from version 3.0) to “woocommerce-old” and then immediately rename rename “woocommerce-new” to just woocommerce.

      So what you have done as a result of the above is swapped one version of woocommerce in its entirety for the other. You are now back to the old, safe, compliant version of Woo.

      Although the new woo did a db update, in adding some new tables and fields (we are still assessing the details) to our best knowledge the db upgrade that came with Woo Ver 3.0 did not delete any tables or fields (that would be exceptionally rare thing to do by any wp developer) and so reverting your Woo install is not affected by the db changes.

      We have tested reversion and not yet found any consequences.

    • Your issue isn’t WooCommerce directly, the issue you have is caused by the WooCommerce Quickpay Extension you have installed.

      You can determine what plugin has the error via the path that is displayed wth the error. This is how I knew the source of your issue.

      The developer of the WooCommerce Quickpay extension must not have been aware of the changes coming in WooCommerce 3.0 and had not updated his plugin to maintain compatibility.

      Yes the issue is due to changes in WooCommerce 3.0, but extension and add-on developers need to stay on top of what is going on with the plugins they are building add-ones and extensions for. Had this developer been on top of things he would have updated his plugin in advanced. Or at least on the same day as a WooCommerce 3.0.

      We deal with these kinds of issues when we make major changes to Gravity Forms. It’s also why we will have long beta cycles when there is a major change. To give 3rd party developers plenty of time to update their custom code, add-ones and extensions.

      I don’t know how long WooCommerce gave its 3rd party developers to prepare for these changes. But we try to give plenty of warning. But you can only do so much. It’s up to the 3rd party developers to stay on top of things.

      • Thanks for the info. My first thought was also to deactivate Quickpay and see what happens. I can see that the error warning disappears from the control panel, but the shop catalogue still isn’t showing, just shows bread text *Fatal error*: Uncaught Error: Call to a member function get_id() on null in /var/www/ outdooricentrum.dk/public_html/wp-content/plugins/woocommerce/ bla bla bla…

        Someone else told me, the problem was that the shop database was not updated prior to updating Woocommerce.

        I was thinking it would be a good Idea to reverse to the old version of Woocommerce, which can be downloaded, but It seems that I would have to delete the 3.0 Woocommerce plugin first. That doesn’t seem safe, or is it?

      • Hi Carl, when you push a major update do you immediately pull support for compatibility with the last version? That’s what happened here with WC 3.0 and third party Themes/Plugins.

        Deprecation notices are great and inform Theme/Plugin developers and integrators of the need to update their code to match new standards but fatal errors don’t help anyone.

        • We always try to maintain backwards compatibility. But sometimes breaking changes are required.

          When it comes to hooks/filters, etc. we’ll deprecate them and push developers to use the new hooks/filters, etc.

          BUT sometimes you have to implement changes and it’s a situation where deprecation and backwards compatibility isn’t possible. Database changes are an example of this.

          So there are most certainly situations where breaking changes are unavoidable. When that happens we give 3rd party developers plenty of notice and time via a long beta and release candidate phase prior to public release.

          From what i’ve seen the WooCommerce team gave the 3rd party development community 3+ months to prepare for the WooCommerce 3.0 changes. That should be ample time for them to make changes to their customizations and extensions.

  5. Most plugins and theme developers stuck on the old select2 as the V4 of select2 removed the order of selected items and presented them alphabetically. There are several discussion on github on this. Not a single one presented a working solution of keeping the selection, saving the selection, reading back the selection and setting the selection in the order selected. In v3.48 of the script this was so easy. They killed a nice ability of that script by updating and never cared about providing a full working solution for those who needed the order of the selected items as they are selected. So many developers using the script kept on using the old version. And now Woocommerce creates a conflict by updating that script to version 4.03. This is what i dislike so much every time updates are released. They should have given more rumours about what they were doing.

    • Thanks Neo – that is what I pointed out as well. I bet we are both on the same github threads for select2 for the same problems.

      Its idiocy all the way around and only we who actually give a hoot about our customers care about thoroughly investigating amendments before releasing a new build and then we are always backwards compatible. Every time Woo or WP updates its a trainwreck. The action to use Ver4 of Select2, given its known conflict with all prior version, can only be construed as a deliberate attempt to sabotage external premium themes and plugins, and I am not alone in believing this.

    • With all due respect, having had to post an instruction to our userbase on how to do find the prior versions, it is our opinion that your average DIY WP user, who is not normally hibernating in the plugin codex daily, is not understanding the nuances of the revised plugin pages. And that speaks to a fault in design and usability of the codex.

      And can we convince the codex to provide filtering of plugins by most recently updated, and skip the plugins that have not been updated in 7 years? Nope! In fact the filtering is even worse now then before.

  6. Note: This comment is only related to lack of preparedness by 3rd party WooCommerce developers. I can’t speak to the Select2 or theme related issues.

    I see a lot of comments giving WooCommerce grief for making breaking changes.

    I also read that WooCommerce 3.0 had an over 3 month long beta and release candidate cycle before being released.

    It appears some of the issues are related to the use of WooCommerce extensions that were not updated to be compatible with the 3.0 release

    How much time do you need to prepare?

    Products like WooCommerce, and our own Gravity Forms, can only do so much to get developers prepared for breaking changes.

    If a WooCommerce extension isn’t working with WooCommerce 3.0 it means it’s developer wasn’t paying attention and simply were not prepared for the release of 3.0.

    They had over 3 months to prepare.

    If you want to get angry at anyone, yell at the developer of the WooCommerce extension you are using that isn’t compatible. Or consider using a different extension from a developer who isn’t asleep at the wheel.

    • Those extensions developers probably do not make enough money to justify keeping up with the changes in WC and fixing whatever is needed, because they are busy with their day jobs. You can blame them for being reactive instead of proactive, but the blame should be shared with all the people that didn’t even bother to email them and ask them if they are compatible, and just clicked the upgrade button hopping for the best.

      • Pro Tip:

        Your business should not rely on WooCommerce Extensions that are not actively maintained by their developers because they can’t justify keeping up with changes in WooCommerce.

        Just like your business should not rely on WordPress Plugins that are not actively maintained by their developers because they can’t justify keeping up with changes in WordPress itself.

        WordPress Plugins are not static. You don’t write them once and then forget them. The nature of WordPress is it is always evolving and changing and plugins need to keep up.

        The same goes for add-ons and extensions to popular WordPress plugins like WooCommerce, Gravity Forms, etc.

        Don’t just use any WordPress plugin, WooCommerce extension, Gravity Forms Add-On, etc. Make sure the developer behind it isn’t going to leave you hanging.

        WooCommerce gave their development community 3+ months to prepare. That should be ample time.

        If a WooCommerce extension you are using wasn’t updated because it’s developer doesn’t have time to maintain the plugin that they made publicly available… that is not WooCommerce’s fault. That is the 3rd party developers fault for not maintaining a plugin they released publicly AND the users fault for not doing their homework on the developer behind the 3rd party WooCommerce extension.

        If you build a WooCommerce extension you should be following and paying attention to the WooCommerce core development. If you do that, you won’t have situations like this arise. It’s that simple.

        • While I fully agree, this is actually easier said than done. I had a bad run with ninja forms and there was just no way to predict it, after all it has 600k users and is a profitable business, so how can anyone predict that when you have a problem their support answer will be equivalent to “restart your computer”. It is just impossible, to predict how long and what quality of answer you will get for a support issue, And as you said in the other comment, no plugin developer can test against to the various settings that there are in the wild.

    • People are yelling at the select2 script developers for more then a year to fix issues with their script. They didn’t care. Woo included a script that lost abilities it had before working without any issues.

      It is not that plugin developers are sleep at the wheel. If your car now has square wheels would you drive it? Or keep the old round ones?

    • Hi Carl – Interesting that you appear to be pointing the finger at 3rd party developers for the epic WC 3.0.0 release breaking live stores –
      WC 3.0.1 – out 2 days after 3.0 released – 43 Bug Fixes

      I see even plugins that where updated for WC 3.0 before WC 3.0.0 release are having to push upgrades with Patches – eg. WooCommerce Subscriptions http://dzv365zjfbd8v.cloudfront.net/changelogs/woocommerce-subscriptions/changelog.txt – 2 releases with 9 bug fixes the day after release and store owners still losing all subscriptions products https://wordpress.org/support/topic/subscriptions-not-working-after-update-3-0/#post-9003680

      WooCommerce was notorious for breaking tens of thousands of stores with each major version upgrade when WooThemes owned it – had hoped under the ownership of Automattic that would change – but no.

      What I’ve always argued is that WooCommerce should as far as possible never do this – you are actually playing with peoples livelihoods here – these are not blogs, they are live stores owned by businesses. But still they continue to do so –

      I wonder if Automattic has thought about the possibility of WC store owners filing a class action for loss of income due to something like the release of WC 3.0.0 that breaks every dependent plugin and theme?

      Lets see – 100,000 store owners (not developers – the actual business owners) lose US$1,000 in sales due to 3.0.0 breaking their store – Class action = US$100 million – scary

      • I am sorry, but I didn’t get the memo…. why no one had told me that (on the site I am finishing right now) I **have** to upgrade **ASAP**.

        As you said we are not talking about blogs, we are talking about people’s livelihood, so how reckless can shop owners be? Can you imagine a real world shop replacing its POS/credit card processing/whatever other essential utility with a new thing without testing it before throwing away the old one?

        Reckless people that do not do minimal common sense steps to avoid potential loss, rarely can sue for anything. They will need to prove that the WC EULA promised them that there are no bugs and it will work well with their specific sites to prove that they had a contractual reason to expect things to work, before any lawyer will be willing to waste his time to look into representing them.

      • If you have a web site that you rely on for your livelihood you should have a staging site that you test plugin updates on before deploying those changes to your live site or updating the plugins on your live site.

        Nobody says you have to update plugins on a live site the day a major feature release is made available via automatic update. You shouldn’t be doing this.

        If the site is that important, if you could potentially lose thousands of dollars for a few hours of downtime due to an update issue… then you should be afford to have a development or staging site that you test updates on first before applying those updates to your live site.

        Developers of plugins like WooCommerce, Gravity Forms, etc. can’t test for every single scenario. There are simply too many themes and plugins out there. The way WordPress is architected these things are all intertwined and a theme and plugin can interfere or break another plugin. That is why having a staging site where you test major updates is something a serious business site needs to have in place.

        If a staging site was in place and the update tested on it first… the issue would have been immediately apparent and they could avoid updating the live site until they figure out why it didn’t work on the staging site.

        Follow best practices and your live site won’t get broken because of a plugin update.

        • Hi Carl,

          Thank you for teaching us all about best practise for website owners – we as web developers and Hosts actually do that and we see many of our premium plugin clients do the same .

          17 days on from the release of WooCommerce 3.0.0 we still have not upgraded our client sites to 3.0 + and many of our plugin clients have not upgraded because there are still bugs showing up.

          Since the release there have been 4 WC Maintenance Version upgrades with a whopping 118 Bug Fixes.

          Our team has done nothing else for the last 17 days other than work on this – it is frustrating to patch and release maintenance versions for plugins for issues caused by the WC 3.0.0 that are then corrected in another patch release (4 in 17 days).

          Re backward compatibility – we have one plugin WooCommerce Quotes and Orders that we had to build 15 complete new templates for WC 3.0 compatibility because the new version broke all previous templates – that plugin now has a full set of templates for WC versions 2.0, 2.2.0, 2.4.0, 2.5.0, 2.6.0 and 3.0.0 for backward compatibility – because each of those version broke the previous version templates.

          We basically have to factor in that each time WC puts out an x.0 or x.x release , that as a team we will spend up to 1 month upgrading and patching our plugins and themes for compatibility.

          WordPress Core major upgrades in the past have not caused us anywhere near the same headaches. It is just a different philosophy I guess – WP core have a focus on improving WP without breaking everything – the WC team believe the only way to improve WC is to break everything, over and over again.

          • Well said. Maybe Woocommerce should test their updates on the 20 – 30 top-selling / used themes and plugins (especially the woo themes plugins and other top plugins that relate to Woocommerce) before releasing updates.
            These are easy enough to identify. Whether they argue that theme and plugin developers have time to test with beta releases or not, the fact is that they are causing massive disruption with their present systems and procedures and have a duty to find better ways to work with the WordPress community to minimize this. I am sure that many people are now looking closely at all alternatives to Woocommerce and maybe even WordPress because of this.

  7. I just discovered that even WOO has issues keeping product items in selected order with the new select2 script.

    F.e. select 3 upsells in random order and save the product. Now you want the middle upsell product to be last in order. Delete the middle one from the upsell products and select it again. One would expect that it will be added last to the item list of selected upsell products but it will go back to the middle position. If however you save the product first after deleting the middle one then go back to the upsell products field and add the deleted upsell product back in again it will be added at the end of the selected products and you have it at the correct location. Very cumbersome !

    This is caused by the new select2 script. In the old version it was just added ad the end of the selected items and no need for a extra save of the product.

    This was never a issue in the pre woo v 3.0 versions. By changing the select2 script of which its developers say that it is a mayor and better update they wrecked that nice ability to keep the selected order. Regardless the threads on github pointing this out they never cared about providing a solution from within the script itself. One would normally think that when a script evolves it becomes better and old abilities are enhanced. They just killed the best ability that script had.

    Also if you dont grab your items from the database but use a predefined ul li list with all the elements that can be selected. First of all one has to use some fixed code to keep the order of the items that are selected so they dont sort in the order of the selectable items. But when reading back the selected items, after a selection has been made, they are sorted the way they appear in the list of selectable items. Now one has to pre-sort that list of selectable items in the order of the items that are selected to keep the latter in the correct order. This is utterly stupid.

    But by sorting the predefined list of selectable items to keep the selected items in the correct order you loose the ability of having the items that can be selected in a nice alphabetical order.

    In short i can understand why developers kept the old select2 script running. And now Woo crashed that ability.

    • The “new” select2 script is more than a year old. Carl above complains about plugin developers not getting prepared for the new version, and same can be said about automattic. They had a year to fork the script and make whatever changes are needed to keep the functionality working as expected, and unlike the plugin developers they do not have any excuse about money or man power to do it.

      When you distribute a code with a 3rd party library included you should be ready to “own” it as if you have written it. Complaining that the library do not do things the way you want them is pointless, it is open source, put your coding hours where your mouth is.

      As for keeping the “old”, that of course would break many plugins that use the new version, and with time there will be more and more of them, and of course there will never be any maintenance to the old version so if one day some browser will decided that it changes the way it handles multi select everybody will start rushing to get the new version because their sites will be crushing…. not a very good scenario.

      People need to get used to the fact that in the real world outside of wordpress features actually get deprecated from time to time and people that depend on them should A. Test the beta version and raise problems **before** release, an B. Have plan B

  8. Wonderful. 3.0 breaks a bunch of things, costing us countless hours of costs in trying to figure out what the heck was changed.

    Worse, it causes a number of other issues because many other things have to be updated since we use several additional plugins.

    When big changes are coming, they should keep in mind those who have spent a lot of time and money using your products.

    This is very frustrating.

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.