[Enhancement]: Aperture Theme > Module Action Icons incorrectly aligned when inside FluidFull Pane

[Timo-Breumelhof]

Is there an existing issue for this?

• [x] I have searched the existing issues

Description of problem

When you place an HTML module in the Fluidpane at the bottom, the ModuleActionIcons look like this.

In the content pane:

On my own full width Panes it looks like this (for my own reference): But that's probably because I overrule a lot of DNN's CSS by default.

Description of solution

Fix this so it looks the same in all panes..

Description of alternatives considered

No response

Anything else?

No response

Do you plan to contribute code for this enhancement?

• [ ] Yes

Would you be interested in sponsoring this enhancement?

• [ ] Yes

Code of Conduct

• [x] I agree to follow this project's Code of Conduct

[jeremy-farrance]

We've seen this for years outside of Xcillion. I am not sure it is the most correct fix, but in our themes we dnn-reset and clean up always giving the

containing the actual top level ActionMenu a right: 1rem; and unset the left:.

body.dnnEditState .actionMenu ul.dnn_mact {
  left: unset !important;
  right: 1rem !important;
} 

I believe the real problem is the JS calculations for left:, but I have no plans to crawl around in code that is probably 10-15 years out of date.

[Timo-Breumelhof]

@jeremy-farrance IMO the code for the positioning is not robust enough. This has annoyed me forever and just spent some time on this... I'm preparing this: https://github.com/dnnsoftware/Dnn.Platform/compare/develop...Timo-Breumelhof:Dnn.Platform:feature/6801-Module-Action-Menu

Seems to fix the issue and works correctly in my own theme. I'll test on some other themes before I do a PR..

Xcillion on DNN 10:

Aperture:

My test Skin:

[Timo-Breumelhof]

I believe the real problem is the JS calculations for left:, but I have no plans to crawl around in code that is probably 10-15 years out of date.

Which is the reason I never did, but now I decided to do that anyway.. Could be modernized (all jQuery still), but my fix seems to at least fix the issue of the position

[jeremy-farrance]

I can confirm your fix works for our AccuTheme too!

[Timo-Breumelhof]

@jeremy-farrance I tested on my own skins; all fine, but on certain DNN Go Skins, the position is incorrect. It seems to be off by the Persona bar margin (80px), so that seems fixable. I'll get back when I have a fix.

[jeremy-farrance]

I am mildly curious about two things.

1. Your solution adds display: flex - what is this doing or fixing?
2. What is the reason for not switch from using a) left: and calculating the right edge when b) right: 0 eliminates any need for calcs?

[Timo-Breumelhof]

the flexbox makes sure the icons are inline not below each other

Unfortunately someone decided not to place these action menus inside the module but at the bottom of the page (body).. I don't see how using "right" would eliminate calculation as they are placed with position: absolute relative to the body?

Moving these to de rendered inside the "drag bar" would fix it all, but that's a major change..

I just got it working one most skins but one.. As you said "don't touch ancient code" ... :-(

[valadas]

I agree that moving it inside the drag bar sounds like the right fix but it may be a large proposition. I am not in love either with the way it works now, so I would be in favor of a "quick-fix" here...

[jeremy-farrance]

I took another look at ModuleActions.js (see line 379 or so atm) and I feel like the change could be fairly minimal. But it probably depends on more expansive knowledge of how edge cases work here.

Here is the existing code that just appends it to the ID'd place in the

        if (count > 0 || supportsMove) {
            var $form = $("form#Form");
            if ($form.find("div#moduleActions-" + moduleId).length === 0) {
                var menu = $("<div></div>", { id: "moduleActions-" + moduleId, class: 'actionMenu', });
                var menuRoot = $('<ul></ul>', { class: 'dnn_mact', });
                menu.append(menuRoot);
                $form.append(menu);
...

Instead of $form.append(menu); we do something like

              var $moduleContainer = $("div.DnnModule-" + moduleId);
              // Insert as the first child within the DnnModule-NNN wrapper
              if ($moduleContainer.children().length > 0) {
                  $moduleContainer.children().first().before(menu);
              } else {
                  $moduleContainer.append(menu);
              }
              ...

Then we replace the top: and left: positioning with top: 0 and right: 0; and delete the position() and watchResize() and other unnecessary stuff. And now the menu is right where it needs to be when revealed regardless of viewport width.

Anyhow, its just the concept of an idea. But after poking around it seems easier than I originally thought and would result in more easily controllable behavior via CSS (and theming) as well as get rid of a fair amount of code. Another plus? All the changes are in this one file.

Thoughts?

[Timo-Breumelhof]

IMO injecting inside the drag bar is the best solution, but I'm worried this will break Themes / skins that "fixed" the current alignment issues..? I saw that with the DNN Go theme I think (did not look into any more TBH).

If we change the behavior and the icons appear off screen (in a full width pane for instance) due to "fixes" in a Theme, that's a serious issue for an Admin. I think inline instead of "positioning" would be the way to go for DNN 11? Maybe I should drop trying to fix the styling in DNN and add a fix to the Aperture theme for now.

Then for DNN 11 we "make it right". (and maybe work on the styling that the same time as the icons look a bit clumsy right now IMO ?)

[jeremy-farrance]

I agree.

Another round of thinking... Its probably too much work, but another option would be to add a per-site Setting that simply toggles the old/current vs. new ActionMenu output. That way people could switch to it and switch back if it causes problems in their theme. Then in DNN v11, the new way becomes the default and the admins have the option to toggle back to the old way. Then in DNN v12 we drop the old way.

[Timo-Breumelhof]

Well, IMO there's no real need to have a switch if it just works correctly in DNN 11..?

[jeremy-farrance]

As a developer, I choose never to believe that I could have think of everything the user or another designer or developer might want to do. :)

[Timo-Breumelhof]

I like that concept, but as long as we keep the CSS overrule-able we should be fine, right? (talking about the in-place version not this issue)