[#30476] - [4.1] Add inline editing for articles
- Closed
- 21 Oct 2022
- Medium
- Build: 4.1-dev
- Draft PR
- # 30476
- Diff
- johndeutesfeld:inline-editing
- Failure continuous-integration/drone/pr Build is failing Details
- Success continuous-integration/appveyor/pr AppVeyor build succeeded Details
User tests: Successful: Unsuccessful:
Summary of Changes
This PR adds frontend inline editing functionality to the default single article view (and possibly more modules in the future).
When hovering over editable elements, a border indicates the ability to change them inline. This aims for quick fixes in case of mispelled titles/words and removes the need to open the dedicated edit page and do the changes in there. The dedicated edit page still persists for other changes like permissions etc.
Right now the PR only targets the default article view but with a more abstract implementation and the use of the HTMLHelper Class the aim for the future would be that adding the HTMLHelper call with a few changes to the form makes possibly every module inline editable.
In the backend there is now an option which allows to enable/disable the inline editing functionality. Right now it is located within the article tab but may be moved to the global options if the inline editing is available in more places. Further the inline editing feature is only accessible to users who are allowed to edit.
Testing Instructions
- Checkout this branch
- run
node build.js --compile-js - visit an article page while logged out
- try to hover over the title or the text of the article (nothing should happen)
- log into an account which is able to edit
- hover over the title or the article text -> a border should appear which indicates the ability to edit
- click into the field and edit something
- click somewhere out of the field, the article should be saved with the new changes
- visit another site and come back, the changes should be persistent
- go to the backend, find the inline editing option and disable it
- inline editing should now not be functional anymore
Actual result BEFORE applying this Pull Request
No inline editing features whatsoever
No enable/disable inline editing switch
Expected result AFTER applying this Pull Request
Inline disable/enable switch is present
On hovering over editable elements the border indicates inline editing
On clicking on editable elements the editor is activated and changes can be made
On leaving the field the changes are saved
Edit:
Outlook and further changes
As pointed out there is still work that needs to be done in order to achieve an inline editing functionality that is suitable for several modules in Joomla. For further implementation I'll quickly outline the current structure and possible approaches.
The ultimate goal would be to achieve inline editing funtionality by calling the HTMLHelperClass's function for inline editing and assign classes to the elements that should have the inline editing functionality.
Right now there are a few things that need to be changed in order to achieve this goal:
- find solution to currently used form
- remove all hard coded elements
- data-handling
- TinyMCE as the standard inline editor
- user feedback
1:
To save the edits which were made in the inline editor there is currently a form used which works similar to the form of the dedicated edit page. Two issues stem from this approach: The redirection which is currently prevented by redirecting to a dummy iframe on the same page and the construction of the missing form arguments via the js file that elsewise would miss and cause the save function to fail. It needs to be decided if this form is actually needed or a simple presentation is sufficient and the saving could be achieved with an AJAX request instead of submitting a form.
2:
As pointed out before the JS file constructs the missing arguments so that the controller accepts the submitted form. The ultimate goal for the inline editing would be that at no point in code one could tell for which item the inline editing is used right now. This could be achieved with a greater level of abstraction.
3:
Additioal implementation is needed with the data handling as well. There needs to be a concept which regulates how data is collected, sent and extracted + saved that implements the level of abstraction that is desired, maybe the data class can be helpful for that.
4:
We may think that TinyMCE is a good choice as an inline editor but ultimately the user should get to chose what editor should be used. It just needs to be clear that right now a lot of the functionality is carried by TinyMCE.
If there should be several inline editors and a plain text editor in the case of no "smart" editor there are several changes that need to be made (test which editor is available, copy functionalities of TinyMCE and provide them to non editor views, etc)
5:
It may be useful to add any kind of user response to make clear if the inline changes are saved or not. Common message alerts should be avoided to prevent making the quick edits seem "heavy" regarding to usability. Working with a little "saved" an "unsaved" sign or a colored dot might be a choice.
Ultimatedy we'd like to point out that this is actually not a finished product. We began coding for Joomla only a few weeks ago but are glad to introduce a proof of concept of an actual inline editing feature for the whole Joomla! CMS. If you want to pick up the next steps of implementation you're very welcome. If there are any questions, suggestions or tips please join the discussion below.
Votes
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Administration com_content Language & Strings Repository NPM Change JavaScript Front End Libraries Modules |
| Labels |
Added:
?
NPM Resource Changed
?
|
||
This requires tinymce - what happens if the user doesn't have tinymce set as their editor?
Or they have tinymce plugin disabled
Actually that shouldn't be a problem due to the fact that Joomla! ships with TinyMCE. In this implementation the inline editor directly links to the code of TinyMCE instead of the plugin. So if the user disables TinyMCE as their editor, they'd still be able to use the inline editing. This was one of the reasons we decided to implement it that way, to assure that even if the plugin is disabled, the feature still works.
If you are saying that it works even if tinymce is disabled then that sounds wrong to me. If I disable a plugin then I would not expect it to work. Perhaps a check and notice when you try to enable inline editing
BTW I am commenting because I really want to see this implemented
@johndeutesfeld please note that @brianteeman is right, this implementation should follow the current Joomla editor chosen by the user, either in the global configuration or under user preferences. It's not acceptable that it's something hardcoded only for the TinyMCE editor, that could even be totally disabled or unwanted by a user.
If an editor is disabled, this feature should work using a plain textarea element, the same as the normal editing in backend/frontend.
Anyway i would not call this feature a real 'inline editing' given that it should apply even to titles, etc It seems to me rather something like a shortcut to the editor for an article content
Disabling the tinymce plugin inlcuding the inline editor as a whole would cause that the whole editing feature disappear in this view. Anywhere else where tinymce is in use, if the plugin is disabled an alternative would be in use. But in this articleView no alternatives to inline Editor are given. Showing a simple textarea field instead sounds somekind similiar to the inline editor feature
@joeforjoomla yes it is a shortcut. It wasn't intended to replace the whole editorView. Just a possibility to edit very quickly.
If you are saying that it works even if tinymce is disabled then that sounds wrong to me. If I disable a plugin then I would not expect it to work. Perhaps a check and notice when you try to enable inline editing
You definitely got a point there. We considered this as well and came to the following conclusion:
IMHO the most relevant scenario is that the user does not want to use TinyMCE as their editor but is somewhat interested in the inline editing feature. With this implementation the user is still able to use the inline editing feature even if tinymce is disabled, as long as he wants to. If he doesn't want to see any tinymce in his project he can just disable the feature.
The point I want to make is that the majority of functionality (e.g. back buttons, coloring, etc) as well as the changing the fields to editable fields comes from tinymce itself. Choosing another editor for this would result in far more code for far less functionality.
Still I get what you're saying and it totally makes sense to me. We just thought it'd be better to give the user the option to use the inline editing feature even if he does not want to use tinymce for the rest of his project, if that makes sense.
Still far from perfect though, thanks for your input on the subject.
Also I might want to add that there is future work to do on this feature which includes some of what has been mentioned before. I just finished writing this draft PR when I had some time on the train ride and did not think it'd get so much attention before I could finish it.
I'll edit this PR and add the future work and outlook soon.
IMHO the most relevant scenario is that the user does not want to use TinyMCE as their editor but is somewhat interested in the inline editing feature. With this implementation the user is still able to use the inline editing feature even if tinymce is disabled, as long as he wants to. If he doesn't want to see any tinymce in his project he can just disable the feature.
If they have made the decision not to use tinymce by setting another editor or even by disabling the plugin for tinymce then you must respect that choice. So at a minimum you must inform the user that this "inline editing" is using tinymce
So at a minimum you must inform the user that this "inline editing" is using tinymce
I think that would be good enough. Ultimately we ship with tinymce, codemirror et al not in a plugin specific media folder but a generic folder (that's been contentious for ages - but ultimately has stayed as is).
Ultimately when people have editor plugins in Joomla right now they expect it to refer to the WYSIWYG editor "blocks" in both backend and frontend. From a end user perspective inline editing is a different beast - and I think we can tell users their inline editor is tiny - but it doesn't bother me hugely (especially as it's behind a flag) that it's use tiny or bust for that "feature" - the main editor area still would respect the editor plugin
given that it should apply even to titles
I'd agree that this should allow people to at least edit the title as well as the textarea (i'd be happy enough with not touching publish dates etc for now)
At this point I would like to point out that we will not make any further changes to this PR. I have reworked the PR once again and as best as I can summarized all the issues that have arisen so far and created a roadmap for further development.
I thank you for all who have participated in the discussion and maybe this PR will one day become the basis of fully developed inline editing in Joomla!
I want to contribute on this. Can I ?
I want to work on PR(#30476) and I think I can contribute. How can I proceed?
What's your plan?
If you have an implementation using some kind of client side store (#30476 (comment)) then sure
I want to work on this. I have been going through the comments. I also plan to submit a GSOC proposal for this. Can the mentors guide me on this, please?
Hey! I am a newbie and I want to contribute to this project. Can someone help me out in getting started please.
Hi I am a beginner and I want to contribute to this project
can I?
Sir I want to participate in that organization for Google summer of code 2022 please help me to do so
This pull request has automatically rebased to 4.2-dev.
This needs a lot work and thinking to integrate it properly into Joomla. Closing this because it is missing a good plan. Thanks for bringing up the idea.
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2022-10-21 09:59:31 |
| Closed_By | ⇒ | rdeutz | |
| Labels |
Added:
Language Change
a11y
?
Removed: ? ? |
||
This requires tinymce - what happens if the user doesn't have tinymce set as their editor?
Or they have tinymce plugin disabled