[#33422] - [4] Hide versions/tags features in Articles if plugins disabled
- Closed
- 2 May 2021
- Medium
- Build: 4.0-dev
- # 33422
- Diff
- PhilETaylor:behaviours-article
User tests: Successful: Unsuccessful:
Pull Request for part of Issue #33418
Summary of Changes
if you disable the Taggable/Versionable plugins the features should "disappear" from the editing of an items that support those interfaces (see table below)
Versionable = Remove Versions Toolbar button, and version note form field
Taggable = Removes the Tags selector in the right hand site
If disabled, On save nothing is done with the version or tags.
This is not my prettiest work, but is a stepping stone and a jump better than it was integrated.
| Component | VersionableTableInterface | TaggableTableInterface | Frontend Also |
|---|---|---|---|
| Content | Yes | Yes | Yes |
| Banners | Yes | No | No |
| Banner Clients | Yes | No | No |
| Contacts | Yes | Yes | Yes |
| Newsfeeds | Yes | Yes | No |
| Tags | Yes | No | No |
| User Notes | Yes | No | No |
| Categories | Yes | Yes | No |
| All other extensions | No | No | No |
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Administration com_content |
| Title |
|
||||||
| Labels |
Added:
?
|
||
| Category | Administration com_content | ⇒ | Administration com_content Front End Libraries |
I believe that option is also taken into account by my code as that is this part:
$this->state->params->get('save_history', 0)I have updated this PR to also remove these features on the frontend edit form
the field is still displayed in the options when the plugin is disabled
Ah now I understand. You want that option to be removed if the conditions are not met for it.
Well it would confuse people if they set it to enabled there and it doesnt work ;)
Im struggling to find an existing field that we currently do this for, I dont really want to have to invent or reinvent if you know of another field that magically disappears?
from memory multilingual associations might
| Category | Administration com_content Front End Libraries | ⇒ | Administration com_content Front End Libraries Plugins |
That last change is not going to work as it is making the version history configurable only globally and not per component
No what it achieved was putting it in EVERY extensions config - which was unintended,
ok Im going to give up on the Configuration screens.
Looking under the hood this is all so badly implemented that its a complete mess.
There is no way to accurately determine which components are compatible with versioning. Including reusing the feature on custom extensions.
The ArticleTable doesn't even implement VersionableTableInterface the way the other extensions do!
Some extensions have the "Enable versions" on "Editing layout" tab of their config, others have it else where. If I move it to the Integrations tab that works great - unless there are already fieldsets there and then Joomla refuses to add more fieldsets.
I can revert the last change, which will get us something that is better than what we started with - but overriding the com_config forms - in a reusable generic way - looks like its going to take all weekend of refactoring.
I was so close...
Versionable/Taggable are per TABLE, not per component, but yet the configuration is per component /facepalm
| Category | Administration com_content Front End Libraries Plugins | ⇒ | Administration com_banners com_content Front End Libraries Plugins |
ok Brian I made the impossible possible.
I have removed The two fields (Enable Versions, Max Versions) from the configuration of each component in Joomla Global Config
Now, the configuration fields are part of the Versionable Plugin. Once the Versionable plugin is enabled, the fields will then show in the Joomla Global Config page for the component either 1) On the Integration Tab if it exists (Like in Articles) or 2) on a new tab (like in banners)
This now means this is reusable too.
Eventually I can do this for all the extensions that support Versionable in core (not many of them!) for for today this 2 min job has taken hours and I need a break.
| Category | Administration com_content Front End Libraries Plugins com_banners | ⇒ | Administration com_banners com_contact com_content com_newsfeeds com_tags com_users Front End Libraries Plugins |
| Category | Administration com_content Front End Libraries Plugins com_banners com_contact com_newsfeeds com_tags com_users | ⇒ | Administration com_banners com_categories com_contact com_content com_newsfeeds com_tags com_users Front End Libraries Plugins |
Ok I think this is near complete now. Disabling the Behaviour plugins disables the features, and hides the features. The Tags and Versions config in the options screens also moved to the Integration tab
Please change the legend to be Versions.
There was a reason for this but I cannot remember what it was now. I will take a look again in the morning. I think it was something to do with the banner options page that doesn't have an integration tab But I will work it out again tomorrow
The reason was, if there is no Integration Tab in Options (Like in Banner Options) then it uses that for the new Tab name.
I guess this is ok to show Versions, as it will be the only option on that new tab it automatically creates.
Whoever thought forms, as XML, was a good idea should be shot :)
I've been struggling to present this PR, its a million times better than the behaviour reported by Brian, but its still no where near a perfect abstraction of behaviours.
What would be needed, would be to literally remove versions and tags, and rewrite it from scratch in a fully abstracted way, to the point where the plugins could be even deleted without effecting the site.
Although this PR achieves its aim to remove the fields from components if the plugins are disabled, I still feel that the behaviour are far too coupled to the components, Ive done the best job with what was already there, but with a handful of new events that could be triggered (for example, for toolbars, passing them through triggered events) a better, cleaner abstraction of the behaviour could be done.
The other issue is that the Tags/Version Note fields are not always in the same place in the edit forms, and so there is a little bit of hard coding already going on to place them in the place the designed wanted them (Prior to this PR)
This is not the correct implementation. Components should not be checking if the plugin is enabled.
This is not the correct implementation. Components should not be checking if the plugin is enabled.
Like I said.
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2021-05-02 15:12:00 |
| Closed_By | ⇒ | PhilETaylor |
Almost.
I forgot to document that there is an enable/disable versions option in the component options as well.
