patrick_here

Liew, this is NOT an Elementor question!

As mentioned in the original post, this is a question for “developers who are familiar with the process of creating a WordPress Page Template.” A WordPress Page Template file is a php file that can exist and be fully functional without the presence of the Elementor plugin. The file exported by the Elementor plugin is understood by Elementor – it is very different from a WordPress Page Template.

Okay, I’ve come to the realization that it’s my code that needs to change because it’s not just IQ Block Country that checks the role (ie ‘administrator’ ) rather than capabilities (other plugins do it too). So I’m going to create a new “AdminEditor” role and remove the capabilities from that role rather than removing them from “Administrator”.

Thanks for the great plugin Pascal!

No, true “Super Admin” role exists only on WP Multisite and this is not a WP Multisite. This SuperAdmin role that I am creating via a call to add_role() is really just an alias for “Administrator” but the normal “Administrator” has certain capabilities withheld. For example, the capability of switching the theme is withdrawn from all users with “Administrator” role.

(Apologies for the confusion of terminology in my first post where I used both SuperAdmin and SuperUser. I’m calling the new role “SuperAdmin” but it has nothing to do with the “SuperAdmin” that exists only on WP Multisite)

• This reply was modified 4 years, 6 months ago by patrick_here.

It’s set to fixed width. There are so many CSS Selectors …all on the outermost div. Which selector do you recommend I use to apply the “float:right;” to ?

(I think I tried targeting all of them without getting the desired result)

• This reply was modified 4 years, 7 months ago by patrick_here.

Fabio, thank you for responding…
I am trying to apply “float: right;” to the entire Crelly Slider so that it will float to the right and the text will float around it.
(it would not help to apply the CSS to individual elements …it needs to be applied to the outermost <div> of the slider itself)

• This reply was modified 4 years, 7 months ago by patrick_here.

This has been very frustrating!! I can do this in about three minutes using MetaSlider …but I’ve spent more than a day trying to get it to work with Crelly Slider …without success! Crelly Slider has so many classes (and an ID) impacting the outermost div …it seems like a bit of a tangled mess. It is very disappointing!

Yes, I’m aware that walker follows the hierarchy established by the admin interface’s menu tree and yes I’m aware that its up to the theme to display it correctly.

People are creating these multi-column menus. They are common. I’m looking for input from people who have experience doing it with wordpress (ie: using the user interface in some way; not just hard-coding it in code – I know how to do that) or who might have input on how existing functionality in wordpress code is intended to be used to get this result.

Joy,
Thanks for the reply and the link. It occurred to me that perhaps my question could have been more clear.
Yes I’m aware that I would need to have wp_nav_menu() outputting the menu in some theme file (typically header.php) …that’s the least of my worries.

The wordpress user interface on the admin panel at “>Appearance>Menus>” is based on a hierarchical model …designed for the typical drop-down menu where the menu items are hierarchical. A Mega Menu or multi-column menu does not use that hierarchical model. Instead the menu entries (or “links”) are arranged in columns or in some other visually logical order.

Some people are using the “css Classes” text entry box in the menus interface to give the end user a way of specifying that a specific menu entry should appear in a Mega Menu (and it would probably be possible to code a way for users to specify where in the multi-column menu this particular entry should appear).

I was just fishing around to see if anyone had any best-practice advice on how to implement this – from a high-level perspective. The basic problem is that non-technical users need a way of specifying how they want the menu entries to appear in the multi-column (non-hierarchical) menu. Mega Menu plugins give users an interface (sometimes a very complex interface) to enable many, many users with many, many differing requirements to do this. I’m looking for suggestions on how to give non-technical users minimal, rudimentary control over where specific menu items appear in a multi-column menu – whether the actual implementation in code is via the “css Classes” entry box or via some other method.

-Patrick

Responsive works fine! It was an error on my part!

(Forum moderator feel free to remove this topic if possible)

• This reply was modified 5 years, 5 months ago by patrick_here.

Works perfectly! Thanks !

Okay, I see. The answer is to just use a text widget or similar.

Wow! Thanks so much for that explanation, bcworkz …that is a sufficient explanation and resolves it for me.

Thanks very much but I found the problem….
Originally my code that was calling the “register_taxonomy()” was linked to the “init” hook. But then I changed it and associated it with the “after_switch_theme” hook. That’s what broke it. So the fix was to change it back to using the “init” hook.

If anyone can explain all this to me, I’d certainly appreciate it. Specifically, why can’t I use the “after_switch_theme” hook in a case like this? I thought that register_taxonomy() would simply register the new taxonomy one time (by an entry into the database) and that it would make sense to have that happen immediately after switching to the new theme. I even gave it a high priority number so that it would be the first of several functions to be triggered when I switch to the new theme …but that all didn’t help. Can anyone explain in clear language why the “init” hook is needed in this case and exactly WHEN the init hook is triggered and why my idea of calling register_taxonomy() immediately after switching to the new theme didn’t work?

Thanks in advance for any help.

Thanks cleancoded …that plugin does look like it would do what I’m needing. I was really looking for a solution that I could code myself (without having to reverse-engineer that plugin) but otherwise I would have to go the plugin route.

Yes, I think that what’s needed is a better explanation of what happens when we use the “-i” option (followed by two hyphens) to “sudo”. The error message recommends this:

sudo -u USER -i -- wp <command>

…So the message implies that USER must be a defined user in the WordPress Site but I’m not clear on whether USER needs to be a defined user on the Linux Host also. Of course it’s possible to have a username on the Linux Host that matches the WordPress Site Username. However I was actually running this in a script performing identical operations on eight different wordpress installations (located on the same server) so for this to work they would all need to have one identical username. That’s do-able of course.

I’ll probably try this out shortly …would still be interested to hear input from anyone else who tries it.

Also: I have noticed that apparently it might not be necessary in any case to have the user in the /etc/sudoers file after all.