| Q | A
| ---------------- | -----
| Bug report? | no
| Feature request? | yes
| BC Break report? | no
| RFC? | yes
| Sylius version | 1.1
Today we discussed on Slack with @psihius, John Risby and @stefandoorn the idea of having enabled / disabled taxon.
Following basically the same behavior from enabled / disabled products, taxons should also have this behavior to allow shop owners to work on a taxon without it being public.
In frontend, trying to get the taxon listing for a disabled taxon should return a 404, while in admin, it should be suffixed with (disabled).
Not a mission critical feature, but quite useful some time - from the general feedback. feel free to throw in ideas.
Use case from one of my clients: they would like to prepare a taxon including underlying products without already putting it online available to customers. I know they can turn around the steps (first products, then taxon), but that's not how a client might think. It also would allow them to temporary disable a certain taxon due to availability issues or whatever reason comes up.
It would benefit from an option to either return 404 or redirect to another page (which could be the master category, a 'coming soon' page or whatever the admin wants).
@johnrisby I would include this behavior (404 or redirect or something else) in a plugin (like Upsell plugin or SEO no-error on 404 plugin). but in core, I'd keep it simple. mainly because core != website and on API I would return 404.
Sure, so what? Just return a code (false/null?) and then let the coder decide what to do? Or maybe a function like IsActive() or isEnabled();
Just similar as with a product; enabled property on the entity and in the repository methods filter for enabled = true. As soon as it can't find a taxon, it will return nothing and the showAction in ResourceController will throw an 404.
That's the frontend part probably as far as I can see, but we have to see if that covers all (e.g. showing an active product with a deactivated main taxon..).
good catch: how should a product with a deactivated mainTaxon should behave?
If the mainTaxon is deactivated but it is in another Taxon, it should still be shown in the other taxons. Otherwise it could lead to confusion with users (site admins) who will wonder why a product in another taxon has disappeared. The point of this is to disable a taxon, not the products in it completely. If you wanted to disabled the product, that should be done on a product-by-product basis.
@johnrisby I have some more questions: you have Taxon "Cool tShirts" configured as mainTaxon for the product "Green tShirt". when you disable the "Cool tShirts" taxon, if you go to the product page, what do you see in the breadcrumb?
also, if you click on the breadcrumb, if going to a disabled taxon renders a 404, should you see an error or not?
Good question @gabiudrescu . It could default to the next (non-main) first taxon (by date or id etc) assigned to the product?
It could still use the disabled taxon in the breadcrumb but simply remove the link. But it certainly shouldn't link to a 404.
Another option: When disabling a taxon, if any products have that taxon set as their main taxon, the admin is presented with the list of the products and can either change the main taxon or choose another option such as temporarily replace with the first other taxon it is associated with. This makes the UI a bit more clumsy but would be more flexible.
A 'simple enable/disabled' or an 'advanced enable/disable' option would allow both options depending on the needs of the admin (you might be disabling a taxon for 10 minutes because you realise you've messed something up and don't care about these issues, or it may be more long-term - but not permanent (say, a seasonal category, Christmas etc) - and then you'd want to make some changes as above).
I think it's good enough to just leave breadcrumbs as is. The link from product -> main taxon is still intact so the breadcrumb can show. The link will obviously result in a 404, but there is also some responsibility on the admin of the shop to keep things a bit properly working.
In smallest form we can keep RFC then to:
Bonus option:
Bonus^2:
This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in a week if no further activity occurs. Thank you for your contributions.
Can we remove the stale label from issue, @Zales0123? And maybe even 'Do not stale'? :D I believe this is an important feature for many.
Did anything come out of this? @gabiudrescu @stefandoorn ?
Not that I'm aware of, @loevgaard
Thank you, Mateusz!
I think that this issue could be closed because of #11287
Most helpful comment
Can we remove the stale label from issue, @Zales0123? And maybe even 'Do not stale'? :D I believe this is an important feature for many.
Did anything come out of this? @gabiudrescu @stefandoorn ?