Admin Environment Notice for Partner Sites

As of 10:30 AM today, we have added a new feature to our Partner ‘s WordPress Sites and will be adding this environment setting in the microCMS soon.

When you log into your admin interface, you will see a Button up top just to the left of your Username that says “Production” and will be red in color.

By default, Specifically for those sights that are selling products, we have set you at Production, for those sites that are of the Development or Test Nature, you have been set at the appropriate environment.

Please log into your web site dashboards and take a look.

If at any time in the future, you need this environment changed, please get in contact with us at

Proposal: Dropping support for old PHP versions via a fixed schedule

This is a Re Post from a Proposal on Make WordPress.

While most people here will probably mostly know me as a (PHP) developer, I actually have a background in business studies, so when Matt Mullenweg reached out to me to continue the conversation about WordPress dropping support for older PHP versions in an in-person call, I decided to put my business acumen to use and see if I could come up with a proposal which would make sense from a business point of view for all parties involved, be it the amazing contributors to the WordPress project, the web hosts, the plugin and theme builders, the web agencies and the users who often run their business via their WordPress website.

In short, I’m proposing a fixed schedule in which every PHP version is supported for five years. Additionally each WordPress release will receive security updates for four years. In effect, this means that users, at a stretch, would be able to run on one specific PHP version for nine years.

A fixed schedule will make this whole process transparent and will allow all parties to plan for the version drops accordingly.

With Matt’s blessing, I’m posting this proposal here on Make to gauge the reactions of the wider community to my idea.

Please feel very invited to leave a comment whether you agree with the proposal or not.
Mentioning what your involvement is with WordPress and how this proposal will impact you in a positive or negative way, would be very valuable input for further discussions on this.

Chicken vs egg

The situation we are currently in, is basically one of “Which came first, the chicken or the egg ?”.

WordPress doesn’t drop support for older PHP versions until enough users have moved over to newer PHP versions and a significant enough share of the WP users don’t upgrade their PHP version until they really have to because WordPress drops support for the version.

This is circular logic, which as most developers know, never ends well as you end up in an infinite loop where, in the end, neither moves forward.

So who are these users who don’t upgrade ?

Well, while we can’t know for sure, if we look at the figures, we can see some patterns:

Take note of the fact that the percentage of users on WP 5.1 who didn’t upgrade yet is relatively small and only part of that can be attributed to the PHP < 5.6 version drop in WP 5.2.

So let’s look at some likely personas for users who don’t upgrade:

We have the “zombie” persona, sites which are still online, but are not actively updated anymore.
These can be, for instance, sites which were linked to a specific event or other date-related topic which are still online for historical reasons, aggregate sites which automatically re-post from other sites without admin involvement, or spam sites etc.

We have the “overwhelmed” persona, who blatantly ignores all admin notices. We all know why and how this happens. The multitude of notices in the admin area once a site has a few plugins and a theme installed trained this user to ignore them.

Then there is the “laid-back” persona, who has seen the notices, but doesn’t feel any urgency until they can’t update their site anymore.

And lastly, the “business” persona, often with a custom theme and a number of custom build plugins who’d rather move the costs of upgrading those to the next accounting year.

As for the user who feels out of their depth – amazing work has been done by the #site-health team to help those out.
For those users, I like to use the car analogy:

A website is something users will generally use regularly and expect to “just work”. So let’s make the comparison with something else a lot of people use regularly and expect to “just work”.

Say a car. Similar to WP, when one gets themselves a car, you need to familiarize yourself a little with how it works (interface/admin), but then it just runs. You put in petrol regularly (WP updates) to keep it running. Then once in a while, it needs a proper service. Now you have a choice: either you learn how to service a car yourself (read the site health materials and follow them up) or you go to a garage (hire a specialist) to do it for you.
And if you really don’t want to be bothered with all that, you lease a car instead (managed WP hosting solution).

Along the same lines: if you ignore the warning lights in a car (site health admin notices), you can’t pretend to be surprised that at some point it will break down (gets hacked/can’t upgrade anymore). If was your responsibility as a user to act on them after all.

But Juliette, get to the point: how do you think we can get out of this situation ?

Ok, so here goes: I propose a fixed (rolling) schedule for dropping support for older PHP versions.

A fixed schedule means that such version bumps become predictable and with them becoming predictable, they become manageable and plannable.

These last two qualities are extremely important as all parties involved will know well in advance what they need to do and when it should be ready.

The current uncertainty over what WordPress will do leads to inaction, as we saw with two of the example personas, and we can counter that with becoming predictable and reliable with regards to the PHP version bumps.

So I propose that, as of now, we start dropping support for the PHP minor which is more than five years old each December, or if there is no release in December, in the WordPress release which is being worked on at that time.

That would currently look something like this, with the numbers at the top being the version of the WordPress release that December and the numbers at the bottom being the new minimum supported PHP version.

Keep in mind that, per the currently proposed schedule, the new minimum supported PHP version would always already be a version which is no longer actively supported by the PHP project, nor does it have security support anymore at the time it becomes the new minimum supported version for WordPress.

For example, PHP 7.1 was released in December 2016. Active support for PHP 7.1 stopped beginning of December 2018 and security support stopped on December 1, 2019. And based on the current proposal WordPress would still support it until December 2021.

But all those users on old WordPress versions…

Well, WordPress has always had a very liberal policy for backporting security fixes, so as part of this proposal, I’d like to suggest that the WordPress project makes a hard commitment to continuing to backport security fixes for WordPress versions up to four years back.

What that would come down to in practice, is that if a user would always want to use the latest and greatest version of WordPress with the minimum of effort, they would need to ensure their PHP version is updated once every five years.

And if they don’t mind lagging behind a little in their WordPress version, they could even get away with only updating their PHP version once every nine years and still have their website running on a secure version of WordPress.

Now how does that sound ? Is that a liberal enough policy ?

Note: security fixes are currently back-ported as far back as WordPress 3.7. With this proposal, the minimum version of WordPress still receiving security fixes would not longer be a fixed version, but would change to a rolling number.

But what about the users currently on old WordPress versions ?

To solidify the commitment to making this as transparent as possible for the users, I propose we backport the PHP admin notice from the site-health project to the older, still currently security supported, WordPress versions, so that those users will be informed when they log in to their website.

Alongside of that we could ramp up the site-health notices based on this fixed schedule of version drops and committed security fix support.

So.. What do you all think?

Woocommerce Update

Woocommerce pushed a major update today with updates to Core, Admin, Checkout, Rest API and more.

From the Changelog

4.4.0 – 2020-08-18

* Accessibility: Adds alt attribute to photoswipe gallery images. #26945
* Enhancement – Remove the privacy page dropdown from the Accounts & Privacy page. #26809
* Enhancement – Added automatic language pack updates for extensions. #26750
* Enhancement – Improvements for the Hungarian address format. #26697
* Enhancement – Dropdown arrow width was made smaller. #26202
* Enhancement – Add a “No change” option to the “Stock status” selector in quick edit, preselect it when the product being edited is a variable product. #26174
* Enhancement – Don’t request language packs for empty locales list. #27148
* Localization – Added 14 Namibia regions. #26894
* Localization – Change default Greek states names to English. #26719
* Localization – Improved Puerto Rico addresses and improve address formatting. #26698
* Localization – Wrapped price and currency inside a BDI tag, in order to prevent the bidirectional algorithm to produce confusing results. #26462
* Localization – Added Algerian provinces. #25687
* Tweak – Added “order_total” to the wcadmin_orders_edit_status_change tracker event. #26935
* Tweak – Fixed WooCommerce menu for users that can only manage orders on WooCommerce. #26877
* Tweak – Limit nocache headers to googleweblight by default. #26858
* Tweak – Preserve quantity input value when changing variations. #26805
* Tweak – Confirm before running any tool from the WooCommerce Status settings. #26660
* Tweak – Limit stock changes for order items to status methods for consistency. #26642
* Tweak – Custom vendor taxonomy update messages. #26634
* Tweak – Remove HTML tags from plain text email template for Customer new account. #26613
* Tweak – Conditionally change the text in My account to reflect if shipping is disabled. #26325
* Tweak – Show CSV file name in result message when product import is complete. #25240
* Tweak – Improve order details UI to highlight “Paid” and “Net Payment” sections. #27142
* Fix – Remove the dot after the generated password in new account emails. #27073
* Fix – Delayed the execution of all webhooks until after the request has completed. #27067
* Fix – [Importer/Exporter] Fixed the value display of “Published” for children of draft variable products. #27046
* Fix – Removed the extra id parameter added to CLI commands that shouldn’t have one. #27017
* Fix – Added the missing instance_id to the REST CLI command so that shipping zone method commands will work. #27017
* Fix – Add rating_count to order by rating clause. #26964
* Fix – Don’t show premium support forum link if the store is not connected to #26932
* Fix – Incorrect capability used on add order note while creating an user note. #26920
* Fix – Preserve HTML entities from product names in the cart page. #26885
* Fix – Display warning hen leaving settings page without saving first. #26880
* Fix – Remove wc_round_tax_total from shipping tax because shipping prices never include tax so rounding down is not needed. #26850
* Fix – Make the “Please log in” message displayed to users with an existing account a hyperlink. #26837
* Fix – Typo in composer.json for makepot. #26829
* Fix – Layout issue on the checkout page when switching countries. #26697
* Fix – Missing closing select tag to the product exporter category select. #26680
* Fix – Possible PHP undefined index notice before WooCommerce has been configured. #26658
* Fix – A deferred product sync is now scheduled when a product having a parent (e.g. a variation product) is deleted, not only when it’s saved. #26629
* Fix – Stock status of variable products that handle stock at the main product level is now appropriately updated when the product is saved. #26611
* Fix – Discounted prices are no longer underlined in Twenty Twenty. #26609
* Fix – Email link color clash. #26591
* Fix – Remove HTML from error message. #26589
* Fix – Fixed Tooltip flashing. #26558
* Fix – Correctly displays the instructional option as default in the select box for picking a Country / Region on the checkout page. #26554
* Fix – Default option “Select a country…” will now display accurately on Country select box in Cart shipping calculator. #26541
* Fix – Fixed user capability required to view the order count indicator. #26338
* Fix – The filtering widget now works as expected with variable products, displaying those products for which visible variations are available. #26260
* Fix – Added a z-index to the remove button (x) to set the z-order of the element. #26202
* Fix – Don’t change the stock status of variations when bulk editing a variable product and leaving the “Stock status” selector as “No change”. #26174
* Fix – Remove new WP 5.5 meta box arrows from “Order data” and “Order items” meta boxes. #27173
* Fix – After clicking to update WooCommerce, the user will stay in the same page instead of being redirected to the “Settings” page. #27172
* Fix – “Product type” dropdown missing from Product’s data meta box on WP 5.5. #27170
* Fix – Removed the JETPACK_AUTOLOAD_DEV define. #27185
* Fix – Fixed “virtual” and “downlodable” pointers on product walkthrough. #27145
* Fix – Updated tested up to for WordPress 5.5. #27334
* Dev – Update WooCommerce Admin version to v1.4.0. #27378
* Dev – Upgraded to v2.2 of Jetpack Autoloader. #27358
* Dev – Update jest-preset-default version to ^6.2.0. #27090
* Dev – Added a second $existing_meta_keys parameter to the woocommerce_duplicate_product_exclude_meta filter. #27038
* Dev – Remove leftover note for translators in customer-completed-order.php. #26989
* Dev – Allow extend BACS accounts filter with order ID. #26961
* Dev – Add npm run build:packages to npm run build. #26906
* Dev – Add woocommerce_order_note_added action. #26846
* Dev – Add tests for template cache. #26840
* Dev – Add filter to allow disabling nocache headers. #26802
* Dev – Introduce a dependency injection framework for the code in the src directory. #26731
* Dev – Normalized parameters of woocommerce_product_importer_parsed_data filter. #26669
* Dev – Introduced new WC_Product_CSV_Importer::get_formatting_callback() fixing a typo in the method name. #26668
* Dev – Allow set “date_created” while creating orders via CRUD. #26567
* Dev – Allow set a custom as order key using wc_generate_order_key(). #26566
* Dev – Allow set order_key while creating an order via CRUD. #26565
* Dev – Introduced woocommerce_product_cross_sells_products_heading filter. #26545
* Dev – Added the removed_coupon_in_checkout event that is triggered on the Checkout page after a coupon is removed using .woocommerce-remove-coupon button. #26536
* Dev – Remove no longer used styles from TwentyTwenty. #26516
* Dev – Fix error message in wc_get_template() function. #26515
* Dev – Add npm publish script for @woocommerce/e2e-environment. #26432
* Dev – Make WC_Cart::display_prices_including_tax aware of tax display changes. #26400
* Dev – Deprecated WC_Legacy_Cart::tax_display_cart in favor of WC_Cart:: get_tax_price_display_mode(). #26400
* Dev – Add an optional $render_variations argument to in WC_Product_Variable::get_available_variation() in order to allow plugins to avoid performance bottlenecks. #26303
* Dev – Ensure wc_load_cart loads its own dependencies. #26219
* Dev – Clean up deprecated documentation. #27054
* Dev – Update WooCommerce Blocks version to 3.1.0. #27177
* Dev – Added woocommerce_order_item_quantity filter to ReserveStock::reserve_stock_for_order(). #27251
* Dev – Updated docs to make the type in docblock more specific. #27285

REST API 1.0.15
* Enhancement – Introduced X-WP-Total header for product attributes GET endpoint listing the number of entries in the response. woocommerce/woocommerce-rest-api#171
* Enhancement – Introduced X-WP-TotalPages header for product attributes GET endpoint listing the number of pages that can be fetched. woocommerce/woocommerce-rest-api#171
* Enhancement – Introduced the modified option for orderby fetch requests in post based resources. woocommerce/woocommerce-rest-api#226
* Enhancement – Compatibility fixes for WordPress 5.5. woocommerce/woocommerce-rest-api#232
* Fix – Ensured Action Scheduler transients are cleared by “Clear Transients” tool. woocommerce/woocommerce-rest-api#152
* Fix – Corrected the schema datatype for coupon expiry_date, date_expires, and date_expires_gmt fields. woocommerce/woocommerce-rest-api#176
* Fix – Query parameters are now passed correctly when using the batch product variation endpoints. woocommerce/woocommerce-rest-api#191
* Fix – Fix regression and restore backward compatibility for date-time and mixed data types. woocommerce/woocommerce-rest-api#238

WooCommerce Admin 1.4.0
* Enhancement – Move the WooCommerce > Coupons dashboard menu item to Marketing > Coupons. #4786
* Fix – Installation of child theme zip files from the store setup wizard. #4852
* Fix – Center the skip link on the theme selection step. #4847
* Fix – Removed item “profiler” from the menu. #4851
* Fix – PHP notices when hosts block certain WP scripts. #4856
* Fix – Remove new WP 5.5 meta box arrows in the shipping banner. #4914
* Fix – Allow revisiting of the payments task. #4918
* Fix – Use of Jetpack autoloader. #4920
* Fix – Only show WCPay task in US based stores. #4899
* Fix – Polyfill core-data saveUser() on WP 5.3.x. #4869
* Fix – Product types step bugs in onboarding wizard. #4900
* Fix – Center all descriptive text on onboarding wizard steps. #4902
* Fix – Match the requires version to the exact WordPress version number in readme.txt. #4956
* Fix – Change account required text on biz step in onboarding wizard. #4909
* Fix – Fix industry args type in REST API. #4974
* Fix – Update style on shipping banner. #4948
* Fix – CSS Fixes for Business Features Popover ( parts 1&2 ). #4994
* Dev – Add the experimental resolver to WCA data package. #4862
* Dev – Fix linter errors. #4904
* Dev – Fix usage of “package” tag in file headers. #4940
* Dev – Update Jetpack Autoloader to match Woo Core. #4993

WooCommerce Blocks 3.0.0
* Build – Updated the automattic/jetpack-autoloader package to the 2.0 branch. #2847
* Enhancement – Add support for the Bank Transfer (BACS) payment method in the Checkout block. #2821
* Enhancement – Several improvements to make Credit Card input fields display more consistent across different themes and viewport sizes. #2869
* Enhancement – Cart and Checkout blocks show a notification for products on backorder. #2833
* Enhancement – Chip styles of the Filter Products by Attribute and Active Filters have been updated to give a more consistent experience. #2765
* Enhancement – Add protection for rogue filters on order queries when executing cleanup draft orders logic. #2874
* Enhancement – Extend payment gateway extension API so gateways (payment methods) can dynamically disable (hide), based on checkout or order data (such as cart items or shipping method). For example, Cash on Delivery can limit availability to specific shipping methods only. #2840 [DN]
* Enhancement – Support Cash on Delivery core payment gateway in the Checkout block. #2831
* Performance – Don’t load shortcode Cart and Checkout scripts when using the blocks. #2842
* Performance – Scripts only relevant to the frontend side of blocks are no longer loaded in the editor. #2788
* Performance – Lazy Loading Atomic Components. #2777
* Pefactor – Remove dashicon classes. #2848

WooCommerce Blocks 3.1.0
* Fix – Missing permissions_callback arg in StoreApi route definitions. #2926
* Fix – ‘Product Summary’ in All Products block is not pulling in the short description of the product. #2913
* Dev – Add query filter when searching for a table. #2886

So as you can see, lots of dev updates and tweaks, thanks Woocommerce for keeping our shops running.

Once you update Woocommerce itself, you will be prompted to upgrade the data tables as well. Of course if your site is within the DevWorks Network, these updates were applied for you.

screen tagSupport
x Logo: Shield
This Site Is Protected By