In headers, in the existing headline elements the text field is missing so the content cannot be edited (after recent PRO updates)

Support
#1

Since the recent PRO releases/updates (at least with 2.1.4 and 2.1.5), in preexisting header headlines the text field is missing. If new (header) headlines are created (after the most recent PRO updates) then the text field is there, it works fine. If I go to the header headlines created before the most recent PRO updates then the problem is there, the text field is missing so I cannot edit the content (text) of the (header) headlines.

I have cleared Style Cache in Pro -> Settings page and I have deactivated my caching plugin.

I enclose my admin credentials in a secure note.

Regards

PS: at least another user is experiencing the same issue.

1 Like
#2

A screenshot just in case it is of any help:

#3

@CYME

Thanks! I’ve looked into this and have been able to uncover the source of the problem. We’ve discovered that this happens on any headlines originally created from the Hero Header template. The problem can reach farther if that headline is ever saved as a preset and used elsewhere.

The way to repair this is by modifying an attribute of the Headline element while it is inspected.

If you open the Browser’s developer tools while it’s inspected you can run this line of code in the console.

cornerstoneApp.lookup('service:headers/header/inspector').set('inspecting.atts.text_type', 'headline')

If you’d like we can do this for you. Just let us know and we’ll check the headlines in your site Headers.

However, when I tried it (without saving) I realized that you have some custom CSS targeting the headline to adjust the font size. This CSS no longer works because the markup of the element is a bit different after applying the fix.

1 Like
#4

@alexander

Thanks! I can see that your solution works but redoing the custom CSS of all my headers in all my sites (I manage each site in a separate Apex account) will be terribly time consuming.

I can see two posible solutions:

  1. A different fix that does not affect the markup of the element.
  2. A comprehensive list of the HTML elements and/or CSS classes/ids that are being changed by the fix (the one already provided). That would speed up the process of redoing my custom CSS.

I would also like to know if there are similar issues caused by these recent updates. Are there –experiencing similar problems–:

  • other elements created from the Hero Header template?
  • elements created from other Header templates?
  • elements created from Footer templates?
  • elements in Content?
#5

I understand. One alternative would be converting them to Text elements which is how they are currently rendering out.

  1. Inspect an element.
  2. Run the code below in the console.
  3. Save the header and refresh.
cornerstoneApp.lookup('service:headers/header/inspector').set('inspecting.atts._type', 'text');

I tested this on your “Equipo” header and there were no visual changes. If you’d like we can proceed to do this for your other headlines for you.

At this time it only looks like it effects elements that originated from the Hero template. We’ve not observed any other abnormalities like this.

1 Like
#6

@alexander, I appreciate your diligence providing explanations and solutions about this issue, very much, but before we carry on, I would like some clarification regarding:

I had not noticed that they were being rendered out as Text elements! I can see, apart from the originally reported issue (that the text field is missing), that the HTML markup enclosing the headline text is ignoring the option “Tag” –that allows to choose among several html tags: p, h1, h2, h3, h4, h5, h6, div and span–. Everything (in header headlines) configured as html headings (h1, h2, h3, etc) is being output as simple divs! Moreover I am checking one of my sites that is still running PRO 1.2.7 and it is experiencing this issue (not the one originally reported, e. i., text field missing) which in my opinion is a major issue if it ends up confirmed. Because of that I would really appreciate if you can shed light on this matter.

Regards

#7

That is correct. It’s ignoring that setting because when the element rendered the template thinks it’s a Text element rather than a Headline element. Because they are so similar in nature they share a template and it checks the text_type attribute of the element (not adjustable by any control). The code snippet I shared first will correct that value.

Any headers you created with the Hero template will not be using the selected tag for the main Headline.

We will be pushing an update that makes the text_type attribute “readonly”. This means that it’s not stored in the element anymore and will always inherit from the element type. Please don’t update to Pro 2.1.6 without deciding which direction you want to take. The next update will force them to render in their correct form as headlines. This could break opinionated custom styles (like using the descendent selector).

1 Like
#8

@alexander, thanks for your precise explanation and recommendations. I have not made my mind about which path to take yet. Before I would like to dig a bit deeper into the “Tag setting being ignored” issue:

  1. As well as the originally reported issue…Does this one only occur when the Hero Header Template is used or is it affecting other templates (including the Blank one)?

  2. Which PRO version (or subversion) introduced this bug?

  3. I have created a header (for testing purposes) using the Blank Header Template. Inspecting the markup output of a Headline element I have found out that it is not HTML standards (specification) compliant when the Tag setting is set to any value other than span. When the Tag setting is set to p, div, h1, h2 , h3, h4, h5 or h6, the chosen HTML element that contains the headline (text) is nested within 2 spans. That is not correct because those HTML elements can only be nested within parent elements that accept flow content (as permitted content, e. i., as children). The point is that the span element only accepts phrasing content.

References to Mozilla Developer Network

Screenshots

1 Like
#9

Each element has a set of attributes that determine how it’s displayed. The two headline elements in the Hero Template (from the first version or Pro) improperly had an attribute set that caused it to be treated as a Text element. The only other way to reproduce this problem would be saving one of the corrupted Headlines as a preset and applying it somewhere else. Starting from scratch would mean there are no prefabricated elements so you wouldn’t have an issue there. Any brand new headline elements added to a header created with the Hero template would be fine as well.

This has been a problem since the first version of Pro but went unnoticed because the two elements are so similar visually. It was revealed by 2.1.0 because that update introduce some conditions in the controls that check the text_type attribute (which is why the editor control disappeared).

As for the markup, we’ve not had an issue with the nested span tags before (this is actually the first I’ve seen it brought up) but we can certainly just change those to div tags to better adhere to the standard. We’ll make that adjustment for this next release as well.

1 Like
#10

Thanks @alexander for your comprehensive explanations.

Regarding:

I have noticed that the Headline element in both, the Content Builder and Footer Builder also can be improved the same way (it is output nested in spans too).

Regarding:

I think this is a serious issue that may have affected many users for many months, even more than a year in some cases (since April 2017 when PRO was released). Those who have crafted dedicated headers por specific pages believing they’ve been having HTML headings (h1, h2, h3,…) when in fact they’ve been having simple divs…well that may have affected (to a certain extent) their SEO efforts.

Because of that I suggest Themeco team to be clear about this issue, being proactive informing the user base about what’s happened.

Regarding:

I am afraid your test on my “Equipo” header is not a valid example because you did not apply the h1 markup to the Text field, which actually was the value I had selected for the Tag option in my original Headline element. As soon as a heading (h1, h2, h3,…) is applied then my custom CSS stops working and needs to be adapted in order to override the headings (h1, h2, h3,…) general theme styles. And this happens to almost all of my headers in all of my sites :disappointed:.

That means that either solution (modifying an attribute of the Headline element OR converting the Headline element to a Text element) will end up breaking my custom CSS in most of my headers…because I normally put headings (h1, h2,…) within them.

The reason behind this problem is that when I wrote my custom CSS for each of my headers I was not aware that the Tag option was being ignored due to the aforementioned bug.

Can you think of any other solution?

#11

All the builders use the same elements so the markup change will take place everywhere.

We’ve added notes in the changelog about this fix and we’re monitoring the issue. From what I’ve seen with this cycle I don’t think this is effecting many users. There are several criteria just to get to this point including using the Hero header template and adding custom CSS with overqualified selectors to change the font size. If anyone has an issue we’ll be able to help them work through it in support.

I do have one more idea for you. Check the “Equipo” header again. I added this custom style:

.dcr_headline h1 {
  font-size:inherit;
}

That will allow the heading to use the font size set on the parent element where you previously declared it. This will let you continue to convert the Headlines to Text elements and have the least change while restoring heading tags.

1 Like
#12

Thanks @alexander,

In my opinion the notes I’ve seen so far in the changelog are too vague:

BUGFIX: Fix Headline elements from Hero Header template rendering as Text elements and missing controls.

As it’s not mentioning that a crucial control which was still present (not missing) was being ignored: the Tag option.

Yeah that’s precisely what I used (inherit) on other much more complex headers (like the one on the homepage), trying to find a kind of universal fix for all my different headers. The problem is that “Inherit” works fine for some CSS properties and some HTML elements like the heading itself but not for others such as its container. Also I have quite a few media queries in the more elaborated headers to change the flex properties, which make it worse. I still appreciate your suggestion very much.

BTW I do not see any advantage in choosing the “converting the Headline element to a Text element” path. The contrary, I believe that it is a better the solution the first you gave (modifying the attribute of the Headline element) as we keep all the Headline functionality. In the end we will have to adapt the custom CSS anyway. Am I missing anything?

#13

Hi CYME,

That is correct, in the end, you will need to change some custom CSS regarding this. We are sorry for the inconvenience as this was a bug of the original preset feature and there are no other options other than the ones we already proposed and both of them will take some time of yours to fine tune stuff.

Thank you for your understanding.

#15

@alexander and @christopher.amirian I know I’ve been quite insistent on this matter. I must say that despite the fact I will have to go through all the headers of all the sites I’ve built during the past year, amending their custom CSS, it’s OK, as I understand it’s the price to pay in exchange for great innovation. That’s what PRO means to me, an audacious, vibrant endeavour. PRO has certainly become an incredibly powerful tool to do things we could only dream of before.

I want to especially thank @alexander for his kind attention and for the high quality support provided.

Regards

#17

Thank you for the kind words. We do appreciate your understanding in this matter and hope that the solutions above will help you get things worked out. If you need help or advice along the way just let us know.

1 Like
#18

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.