Float action links at bottom too

Maybe it would be a good idea that for paragraphs that are higher than some selected value, the action links become "sticky" and follow the scroll to the bottom? Not sure that it is easily possible to do though :)

Possible, but it might actually be more distracting and as you rightly say, probably troublesome to implement.

I think simply duplicating the links at the bottom will do the job very nicely because it then allows editors to edit the 'thing' that they have just scrolled up to without having to scroll to the top of that 'thing'

This is a good feature request. I have faced the same situation for long paragraphs.

Any movement on this one likely?
It really would be a significant boost for editors to have it.

Hi, I've fixed the float action button positioning issue and created the MR. Please review the MR. I've attached a screenshot for reference.

Hi Tirupati_Singh → ,

I think your patch simply moves the edit link to the bottom but the the whole point of the original issue is to duplicate it so that it appears at the top and at the bottom and as such I think it requires more than simply a CSS edit/addition.

Working on it.

I'm just nudging on this one again because we think it's a really key content-editor-experience issues.

We are using Front End Editing a great deal at the moment and almost every edit involves a scroll back up to 'find' the div.frontend-editing-actions.

The ultimate object of the support request is to make the div.frontend-editing-actions as available as possible and I wonder if in fact, to simply make the existing <div> float relative to the target content element as illustrated below…

This may be just as effective as duplicating it and is arguably an even better solution and possibly easier to implement.

I think it might need to be an optional setting as not everyone will want it.

a.dmitriiev → we have discussed the idea of making the action links more available before, what are your thoughts on this idea and how might is play with what;s happening in v2.x?

Thanks all

That is exactly what I meant here https://www.drupal.org/project/frontend_editing/issues/3440870#comment-1... ✨ Float action links at bottom too Needs review . There is no conflict between 1.x and 2.x version in regards of the display of action links

a.dmitriiev → You're absolutely right -- we had indeed discussed it before!

So I think let's leave the feature as-is then - i.e. simply duplicating the action links at the bottom as I originally suggested.

@Tirupati_Singh → , I'm happy to review anything you may be able to come up with.

Hi @SirClickalot, I've added the float actions link button at the bottom also. The float actions button will stick at the bottom if the page has been scrolled down and the button will stick at the top if page has been scrolled to the top. I've attached the video clip after the fixes, please review the MR.

@Tirupati_Singh → , thanks for having a go at this.

I have applied the patch and I am not seeing what I expected at all, after several DRupal and browser cache-clears, on my site, all I see is a single set of action links stretched out to fit the whole height of the currently hovered Paragraph like this...

Also, even if the sticky action you describe were to be working, I don't think it would be right because as you scroll the browser down the page, you will inevitably end up with your pointer over a different Paragraph and so the Front End Editing (FEE) focus should then be on that new Paragraph.

Perhaps our discussions about, and attempts to implement, stickiness are a distraction here, your solution also appears to involve the reintroduction of JQuery which I'm not sure is a good idea with the future in mind.

The actual requirement of the proposed feature was simply to duplicate the action links at the bottom of the currently-hovered element, irrespective of it's height as illustrated here...

Perhaps we should just start with that, and move on from there?

@SirClickalot, in which frontend_editing version you have applied the patch. As I've also applied the patch in 1.x-dev version and did not get the mentioned issue for float actions link. Will remove the newly added js for adding float actions link at bottom and will start with duplicating the float action link at top and bottom too.

Tirupati_Singh there was a huge work done to avoid using jQuery library in frontend editing, so please do not add it back. I have checked the MR and see that you have added jQuery dependency. It would be nice, if this can be avoided. The code without it would have more chances to be merged.

@Tirupati_Singh → you are quite right, I had patch the production version not the dev - my bad behaviour but at least that explains things.

jbd44 → changed the visibility of the branch 3460126-keep-editing-actions-in-viewport to hidden.

Hi @a.dmitriiev, I've removed the jQuery dependency and duplicated the float action links at bottom too. Please review the MR. Attaching video clip for reference.

@Tirupati_Singh → Nice work! ...

I look forward to the next release ;-)

I have reviewed the MR 69 and there are some things that I would like to be fixed before merging this. Please check.

I have also reviewed the approach from MR 73. Please check my comments there

Working on feedback.

MR 69 looks much better now, but still there are some questions from me. Please check them

Added a new model UI setting for enabling/disabling duplication of float action links at the bottom. The feature can be enabled by visiting the module configuration page or /admin/config/frontend-editing/ui-settings. Input the container height under Additional button settings - Height field for which the additional float action links will be displayed at the bottom too. I've attached the video clips for enabling this functionality for reference.

I can confirm that Merge request !69 enables the extra duplicated action set at the bottom of longer (300px) Paragraphs.

Great work @Tirupati_Singh → !

One important exception that I have noticed is…

When a Paragraph includes a reference (Entity Reference field) [1] to other content with the intention of rendering that content on the page [2], the solution as-is does not correctly assess the vertical size of the rendered Paragraph.

The consequence of that being that we don't get the that second duplicated action link set ;-( [3]

I have tried to illustrate this below…

In our particular use-case this is crucial since many of our pages are made up of content 'embedded' inside Paragraphs in this way.

Since it is not fully working yet, I changed the status to Needs work

What can I do to help move this on?

@sirclickalot, I've fixed the issue for Entity Reference field. I've attached the video clip for your reference. Please review the changes made.

Thanks!

I cannot see an MP4 attached to #36?

Hi @sirclickalot, my bad forgot to upload the video clip for the entity reference field fixes in #36 ✨ Float action links at bottom too Needs review . I've attached the video clip reference please check.

@tirupati_singh,

Yep, that looks to be spot on behaviour.
Great work!

Any chance we can get this great feature built into a release?

I moved the functionality to a separate library, where it belongs to and made some clean up, as the height settings should not be required if duplicate links are not enabled.

Please check the update MR, if everything is good I will merge it and add this feature to 1.8.0 release.

It will also take some time to apply these changes to 2.x branch.

Hi @a.dmitriiev,

I have successfully applied patch 69 to my local version (1.7.3), set up the options and cleared caches over a few times but I am not seeing at extra duplicate floating links at the bottom of long Paragraphs...

What have done wrong?

There is definitely something wrong with how you apply the patch, as the file duplicate_links.js is inside the js folder of the module, you can see it here https://git.drupalcode.org/project/frontend_editing/-/merge_requests/69/... . Make sure that you are inside modules/contrib/frontend_editing folder when you apply the patch.

The commands to run could be (if you are using terminal and your webroot folder is web):

1. Navigate to frontend_editing module folder: cd web/modules/contrib/frontend_editing
2. And run the command curl https://git.drupalcode.org/project/frontend_editing/-/merge_requests/69.diff | git apply

Or if you do it with composer, make sure that you have the following snippet in your composer.json file:

"extra": {
    ......
        "patches": {
            "drupal/frontend_editing": {
                "3440870 - floating links": "https://git.drupalcode.org/project/frontend_editing/-/merge_requests/69.diff"
            },
           ......
        }
  .....
}

Make sure that you don't use MR link in patches section in production.

I have re-structured a bit the config object for duplicate action links, so that it includes the status of the action links and its settings under 1 config property

@a.dmitriiev

Forgive me if I am being a bit dim here but I have gone again from scratch in my local dev site and really don't think I'm appyling the patch incorrectly — I have only applied it in the same way I have all other since the begining of time itself ;-)

The patch file is sitting at the correct places, here it is ullstratyed using th UI…

All other adjustments by patch-69 as as expected; the correct files are modified - it is only the location of the new duplicate_links.js file that appears to be being added in a new js folder in the root of the repo'

As a triple-check and to illustrate via the Git GUI, I have anotheer local D10 site where I test new modules alongside the perrenials and I have added the Front End Editing module fresh then patch again using patch-69.

The end results (show here in the IDE Git management tools) confirms what I have seen...

?

Hi @a.dmitriiev, I've tested the new re-structured changes in the MR !69 and it looks good to me. I've also applied it as a patch and it's getting applied with no errors. And the new duplicate_links.js file is being added to the js directory of the frontend_editing module directory. Didn't encounter the issue mentioned by @sirclickalot in the comment #42 ✨ Float action links at bottom too Needs review . The new experimental duplicate action links button at the bottom functionality is working fine for all the entity bundles, also when using the entity reference field.

Thanks!

Sorry, but I don't know how the file from the module can be placed outside of the module in your case, but this is not what MR is doing and of course the module will not ever be installed in a way, that the JS folder from it is placed above the web root or even outside of the module folder.

So for testing I suggest that you place the new file to web/modules/contrib/frontend_editing/js folder manually and check the functionality.

The problem with the file is 100% in the way that you apply the patch. Any of my changes are not placing the file in the folder that you have.

@sirclickalot, you can apply the patch using composer. If you want to apply the patch using the patch file downloaded locally then put the downloaded patch file in a directory named patches/ which will be in your root directory like drupal10/patches/frontend-editing-69.patch. Then you can add the patch details in the composer.json file as:

"extra": {
    ......
        "patches": {
            "drupal/frontend_editing": {
                "3440870 - floating links": "patches/frontend-editing-69.patch"
            },
           ......
        }
  .....
}

Hope this will resolve your issue.

Thanks both: @a.dmitriiev and @tirupati_singh!

Perseverance

I'm going to keep going with this even at the risk of annoying you both because I just cannot get this working and I'm sure others may havce the same if they try.

Put aside the patching issue.

I'm happy to accept tht there is something 'odd' with the way my IDE (PHP Storm) is applying Patch-69 because and I don't get it at all because it's never behaved that way before but I am happy to put that aside for now and I have manually moved out the js/duplicate_links.js in the correct place manually.

Here's a local tree of my files for good measure...

$ tree ./
./
|-- 69.patch
|-- LICENSE.txt
|-- README.md
|-- composer.json
|-- config
|   |-- install
|   |   `-- frontend_editing.settings.yml
|   `-- schema
|       `-- frontend_editing.schema.yml
|-- css
|   |-- forms_helper.css
|   |-- frontend_editing.css
|   |-- preview.css
|   `-- ui_toggle.css
|-- frontend_editing.api.php
|-- frontend_editing.info.yml
|-- frontend_editing.install
|-- frontend_editing.libraries.yml
|-- frontend_editing.links.menu.yml
|-- frontend_editing.links.task.yml
|-- frontend_editing.module
|-- frontend_editing.permissions.yml
|-- frontend_editing.post_update.php
|-- frontend_editing.routing.yml
|-- frontend_editing.services.yml
|-- images
|   |-- hover_highlight_disabled.png
|   |-- hover_highlight_enabled.png
|   `-- svg
|       `-- plus_circle.svg
|-- js
|   |-- duplicate_links.js
|   |-- forms_helper.js
|   |-- frontend_editing.js
|   |-- preview.js
|   |-- settings.admin.js
|   `-- update_content.js
|-- logo.png
|-- src
... etc.

My experiments

1. Fresh Drupal 10
2. Ensure that page caching and CSS/JS aggregation is OFF
3. Install latest 1.7.3 (release not DEV)
4. Patch with 69 from https://git.drupalcode.org/project/frontend_editing/-/merge_requests/69/...
5. Correct for my local js folder placement weirdness
6. Double check all code in the correct placement - see the above tree from the Terminal.
7. Install module
8. Configure for action with Articles and use of duplicate links.
9. Create very large Article.
10. Clear all caches including browser.
11. No errors in JavaScript console

But still no duplicate links...

Like I said, trying my best to be useful and helpful here but I'm a bit bamboozled given that both you seem to be agreement?

I see what it is, your link to MR is pointed ONLY to one commit, but MR contains of more commits. The complete diff of changes can be seen here: https://git.drupalcode.org/project/frontend_editing/-/merge_requests/69....

I will also attach the patch.

@sirclickalot, the used MR link is incorrect here

4. Patch with 69 from https://git.drupalcode.org/project/frontend_editing/-/merge_requests/69/...

You'll have to use the MR link for the patch : https://git.drupalcode.org/project/frontend_editing/-/merge_requests/69.patch.

Thanks @a.dmitriiev,

I appreciate all you efforts here to get me updated — I have applied the new patch and corrected again the location of the js/duplicate_links.js file.

Everything seemed to be in order but no matter what I try — including uninstalling the module and reinstalling — still no duplicate links!

Anyway, look I don't want to take up any more of your time, I think I had better just wait the next release and report back on findings.

Thank you for being so accommodating.

N

I'm testing this one, seems like @bbruno might be caught up on something else right now!

Updated MR !73 to use the IntersectionObserver API as an alternative to the Scroll event listener due to performance.

Back to Needs Review

There was a decision made to combine approaches from MR 69 and 73 so that they are both available for selection, but it is still possible to select only 1 option.

Bruno, there is still some small fix needed for the floating links approach. Please check it when you have time.

MR updated, please proceed Artem.

Nice one Team, great work, VERY useful.

JUST ONE THING — and apologies if this has already been discussed but since I was the originator of this idea (I think) — but if I chose the STICKINESS option, doesn't it make more sense to have the sticky version at the top rather than at the bottom.

I find it an absolutely invaluable feature to be able to see the links on long paragraphs but I do find myself having to look down once the top-side links disappear.

Am I missing something obvious?

Let's open a follow-up issue for this and continue discussion there.

I have created the new issue here https://www.drupal.org/project/frontend_editing/issues/3481501 ✨ When keeping action links in a viewport with floating links the actions should be sticky on top, not bottom Active

Automatically closed - issue fixed for 2 weeks with no activity.