Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[2.7] Some product functions moved to global scope not backwards compatible or meaningful #12495
As discussed in #12494 I see some product functions unrelated to CRUD that have been moved from product scope to global with no apparent reason or consistency with the rest.
A look at
To make existing code compatible with WC 2.7, it will be necessary to rewrite all that functionality using always-on, type-specific filters provided in the (now global scope) functions. This is the definition of a breaking change and the required "fix" is a step back, since it introduces an overhead that I find unnecessary. Inheritance is a beautiful concept that works.
I'm open to discuss the implications of moving these methods by looking at each one individually. The only understandable reasons for making such a decision are:
Here's a short list of product methods that are potentially overridden by type-specific code and are eaten up by a black hole in
Some more "weird" decisions:
Some good decisions (assuming that changes are necessary):
And some decisions that are unnecessary but can be justified with a bit of head-scratching:
It seems to me that methods that don't directly use product (meta) data have simply been kicked out, without evaluating the potential usefulness/necessity of keeping some of them in product scope (those listed here). The ability to override a method is a central concept of inheritance -- dumping this wonderful "tool" in favor of using filters is... wrong (in the cases summarized above).
EDIT: Edited to make it clear I'm only referring to the listed methods (and not others). Other extension authors may have different feelings about specific methods being no longer override-able. I'm listing the ones I feel are ideally-suited for overriding in child classes.
We're going to have to chat though each of these individually. I don't have time to go through all this second because I'm on support week, but
The resulting CSS class and string is affected by:
The actual displayed HTML for the availability should be consistent across product types. Any changes can be done via the provided filters which are in place still and can be used for any product type.
Unless your special product is introducing it's own stock status (something I don't think we support?), why does it need to be type specific @franticpsyx?
Sorry but this one sounds pointless? If core has no use for a function, only a small subset of extensions require it, and those extensions need to update the deprecated call to a function based call anyway, why can those extensions not have their own function which handles that logic?
Having unused functions in core is the very definition of bloat and ultimately those functions are neglected. A function which outputs the word 'from' seems terribly wasteful. This is legacy from the old days of showing variation prices with that prefix.
Just to get it out of the way, I am not necessarily looking at changes from an "own product" perspective. Some of the listed ones are not overridden in any class I've written.
This is a valid point -
There is a conceptual difference between using inheritance (which was possible until now) and using filters. Inheritance allows you to do a number of things, such as use a different filter to modify the output of an overridden method in cases where this is desirable. Filters are better for general purpose tasks, such as templating.
Filters are more fragile than inheritance and can be overwritten at a later priority.
What does "we support" mean in this context? We are talking about an existing API, not a feature that's no longer supported.
Introducing an extra availability "state" by changing the text - say, "Insufficient stock", is not a template thing. If a product type needs an extra stock status/state, it makes sense to keep at least
Suggesting the use of filters as an alternative is not helpful for the reasons outlined.
So why not rewrite the content of these methods and introduce a template, similar to what's done with
Or why not ALSO move
See the entire text. Perhaps I'm wrong, but
I explained the reasons for keeping it as a global function here:
By (eventually) removing it, every plugin that used it will need to use its own localization context for a very widely used string. I can count at least 5 extensions that display "From:". There's no maintenance overhead with keeping this as a global method. Not keeping this means that every plugin/extension that uses it will then need to have its own style/translation context to display the same thing.