SJF

@mte90 any update on this? ??

I’ve updated the plugin and it works! But just wanted to let you know about one small thing…

When it was active and I went to update it, it said it couldn’t because it couldn’t create a new folder. When I looked, inside of /plugins/glossary-by-codeat/ it was empty. I had to manually download and reinstall and reactivate the plugin. Works fine, and that may have been just my setup for some reason, but thought I’d let you know incase it is a sign of something bigger.

Alright thank you @mte90, I’ll wait for the new version instead of patching it myself ?? thanks!

This is X theme by Themeco with their editor Cornerstone. While Cornerstone and X Theme are REALLY amazing, I completely get where you’re coming from with the opinion that “page builders are the evil”. There are definitely times when I wish there was more control, but unfortunately there’s no turning back for this particular project (deadlines will be deadlines!)

I’ve extracted Cornerstone’s output for that “Training Phase” column so I can show you what I’m working with. Now… don’t freak out… there’s a lot of evil in store here!
[cs_column bg_color="hsl(0, 0%, 93%)" fade="false" fade_animation="in" fade_animation_offset="45px" fade_duration="750" type="1/3" class="cs-ta-center" style="padding: 0 4em 2em;"][x_icon type="sitemap" icon_color="" bg_color="" icon_size="50px" bg_size="" bg_border_radius=""][x_custom_headline level="h3" looks_like="h4" accent="false"]Training Phases[/x_custom_headline][cs_text]Quisque velit nisi, pretium ut lacinia in, elementum id enim.[/cs_text][x_button size="global" block="false" circle="false" icon_only="false" href="/new-users/training-phases/" title="" target="" info="none" info_place="top" info_trigger="hover" info_content=""]View Phases[x_icon type="angle-double-right" class="mvn mls mrn"][/x_button][/cs_column]

Now, this is automagically rendered out into the screenshot I shared above, and like I said – while I definitely agree with your opinion about editors, they’re unfortunately a necessary evil out in the realm of WP. So some sort of compatibility w/ shortcodes and front-end editors is a must for plugins in general to be successful. I think the trick here is somehow parsing the other plugins’ shortcodes without executing them (yet) OR first execute the shortcodes and THEN add the glossary code.

I tried this code out, for fun:

function returnContent($atts, $content = null){
  return '...Start content:::   '.$content.'   :::End content...';
}
add_shortcode('return_content', 'returnContent');

…and that didn’t really work when I placed the opening and closing tags as separate elements surrounding the row. (page-builder view & front-end view)

I’m wondering what the trick would be to ignore the page-builder’s (Cornerstone’s) shortcodes until the glossary is done doing it’s thing… and then executing them, or rendering the built page before Glossary and then having Glossary do its thing?

Thank you very much for your time & feedback!

Here’s an actual use case, which will give an example of what I mean.

Figure 1
Inside of our editor, there’s a spot to place text (denoted by the red arrow here). You can also see, right below it, the HREF for the “button”, which is really just <a class="x-btn">Button</a>

Figure 2
On the front-end, you can see how this renders in the source code. The term here is “phases”. For the heading above the button (Training Phases) I put <a>Training Phases</a> as a temporary workaround… since that’s bad practice… but still, you can see how when it affects the “phases” term in the button, since it’s already in an <a> tag, it unwraps itself of it and breaks the button <a> tag.

Figure 3
Here’s the <a> tag fix in the back-end. You can see what happens is the link hops out of the button link, since WordPress detects two anchor tags and unwraps itself.

Figure 4
And here you can see the front-end view of what happens when we surround the text with <a>

I can appreciate the best practice approach, for sure. I’m just unsure if the [glossary-ignore] shortcode approach will work for actual use-cases out there. It really just depends on the logic the shortcode uses.

Let’s use your 3-column pricing table on your site as an example. Let’s say you have the word “tooltip” in your glossary, and you do not want the entire page to disable the glossary… but you also do not want to have to put [glossary-ignore] around every… single… instance… of “tooltip”, right? So, would the shortcode be able to surround a group of elements?

For instance… let’s say this was how the code was, in the site editor, where you lay out the pricing table, text, images, etc:
[glossary-ignore]
<div>A bunch of other stuff here</div>
[maybe even="a shortcode] or two [/maybe]
[/glossary-ignore]

Given that scenario… would your proposed [glossary-ignore] work in ignoring all terms in between? If so, fantastic!

Thanks @igenius for the workaround! We’ll try to use this for the time being but would really love it if there was a way to just add a class to a parent element to disable the glossary plugin from affecting anything within that element.

The workaround you’ve given us will work as we develop our site but most likely can’t be a permanent fix. We’re welcome to the idea of a custom function, too, which could extend the functionality of glossary using our functions.php – if that’s something you can provide. I’m unsure exactly how that would work, but maybe there’s a way for us to hook a command that says “Hey Glossary – as you’re scoping the site, skip anything inside of .disable-glossary” – is this something you might be able to lead us in the right direction with as well?

Thanks for your support, and we look forward to this update / a possible code to add this functionality!

@freelancephp – This plugin is unloading the FontAwesome styles which my theme is loading. I compared the “Sources” tab in “Developer Tools” in Chrome to compare the site with and without your plugin activated. When it is activated, I noticed the CSS rules for [class^="icon-"], [class*=" icon-"] were gone.

For my particular case, FontAwesome was being loaded in dynamically via my theme. So all of the FontAwesome icons were using the class “icon-*” instead of “fa fa-*”.

To fix this, I had to grab the Font Awesome CSS and paste it at the end of my child theme CSS code. Obviously not ideal (384 additional lines of code) but it fixed it.

Here’s the CSS code. Feel free to remove any icons you aren’t using in order to minimize the bloat: https://pastebin.com/PJ6wF9bH

Bump! ?? Hopefully someone can at least address why this is happening and point me in the right direction of figuring this out.

Bump! ?? Hopefully someone can at least address why this is happening and point me in the right direction of figuring this out.

Kharis — you are a God among men! THANK YOU!

is there not a fix for this? We just need to know how to proceed. If there is not a fix for this, then perhaps we need to allow username generation from email, and then forget custom usernames – but we would prefer to have the ability to validate usernames like emails already have.

Kharis – thank you for your reply — however it is already unchecked.

The issue is not that the username is automatically created based on the email, but rather the username is not being validated upon account creation.

Let me give you an example. Let’s say there is an account that exists with the username JohnDoe, and uses the email address [email protected] — when a user registers on the site and puts their username as anything, but the email as [email protected] – it will say there is a user with that email already.

However, in this case, if a user tries registering their username as JohnDoe, with a different email (even though the username exists) it allows it, and appends a number at the end (in this case, the number 1, making it JohnDoe1 – and the numbers count upwards as more users create accounts with the same username).

tjc-thomas – can you please link to the workaround?

You must have fixed yours because I see no shift.
Also, I found a fix (rigged, but still works).
Apparently I have to add a </div> in index.php for every post I make. So I just added a crap ton of </div> tags at the end, which doesn’t effect anything in any way. (I don’t care about W3 etc)