Page Header Not Showing up

[boston85719]

Anybody else experiencing this? The page HTML header is not showing up in the debugger for me and shows as empty with grey indicating no data values were ever present (ie: no dynamic expressions used), however, I have structured data added correctly, which I’ve validated and had pages indexed in past.

Now, the structured data validators are indicating no items found as well as the debugger showing empty value. Issue is affecting my development and Live site, likely killing any chances of my new content getting indexed properly by Google.

[nsykes]

If there’s no data values at all present, it sounds like a privacy rule issue! Would you mind checking and seeing if the Blog-Posts data type has any privacy rules enabled?

[adamhholmes]

For me, nothing shows in the page HTML header in the debugger… but it’s definitely there in the source code.

Have you checked the actual source code of the page?

[boston85719]

no privacy issue

[boston85719]

@adamhholmes

Have you checked the actual source code of the page?

Yes, it is in the page html header section within the editor, and I believe the structured data testing tool that shows item not found is looking at the source code of the page.

[adamhholmes]

But does it actually appear in the source code of the page?

In my case it definitely does (even though the debugger doesn’t show anything).

If your source code is not showing the HTML header then something’s obviously wrong… otherwise i wouldn’t worry too much.

[boston85719]

Would I need to look at the developer tools?

I am using Google Chrome and from the developer tools I look at console and from what I can see there, I assume the Page Header HTML would be in this area in the screen shot, which doesn’t seem to show anything.

I can see in the console the page title, meta title, description and image information showing up, but I don’t see any other area that would be the Page Header HTML, nor do I see anything that would represent the type of information in my structured data placed into the page header html.

Would this be the correct place to see something if the data was sent to the page properly?

[adamhholmes]

@boston85719

Would this be the correct place to see something if the data was sent to the page properly?

It should show up there… but I’d check the source code directly as well, by right clicking on your page and clicking ‘View Page Source’ …

[boston85719]

Thank you for the help.

I don’t see it in the source code at all.

I’ve submitted a bug report about this.

[boston85719]

This issue was solved by removing from the header area the dynamic expressions of ‘this url’ and ‘website home url’. Neither expression is available in the page header section by default and had been copied and pasted into the header area. By removing them, the page html header is now coming through.

Note, that this issue only started within the last week to my knowledge, and this structured data approach to using a copy and pasted expression for ‘this url’ and ‘website home url’ had been in place and working for over a year (actually 3+ years as I’ve used it in other apps).

I’m now concerned that whatever change Bubble made to make it so errors like this occurred because of a copy pasted dynamic expression not available by default in an input area will also affect other parts of apps that had to rely on the use of copy pasted expressions that were not available such as in conditions on workflow actions etc.

Not sure what the change was or when it was made, but it seems like a ‘breaking change’ that I wonder if it had been communicated with users in any way.

[keith]

@boston85719

Neither expression is available in the page header section by default and had been copied and pasted into the header area. By removing them, the page html header is now coming through.

How many times have I noted that this is bad practice, as noted by Bubble? Lots.

http://forum.bubble.io/t/so-this-is-messed-up-and-cool-at-the-same-time/270670/2?u=keith

Changing "and" to "or" in a Condition - Now Need to Re-Enter Condition

It was noted by @josh that doing this trick (copying an expression and pasting it to a place that would NOT let you construct that same expression) is unsupported behavior and subject to breakage. I had mused about this here: And Josh explains why this is a no-no here: I know this isn’t helpful to you now, @antony , but wanted to point this out to other intermediate to advanced Bubblers as a warning.

Memory Issues: What Data is Loaded when a Page Element has a Type?

Yeah: couple of observations: The issue with page level privacy is the interface simply isn’t designed to enable that. You can craft these expressions (somewhere else) and paste them, but then ANY condition that passes unlocks a permitted value so you wind up with some very wonky expressions (and lots of them to cover all the cases). Implicit OR having to be worked around! Not a good approach. (Though it DOES prohibit data loading… so it’s an option, but a fragile one.) it’s fairly easy to tes…

Showing alert message when another element is focused

Just an aside: There are other expressions like this that can be composed in one place but not in another. While in this case this looks like a bug to me, Bubble has said of other such expressions that if you can build it in one place but not in another, this “build there, paste here” is fragile and subject to breaking at any time (presumably because they really don’t support the thing you’re trying to do and may fix the “bug” that allows it). FYI!

Assigning Concatenated Values to a State

Total aside which may or may not be relevant here: @josh has noted that situations where you can do this (compose an expression somewhere and paste that expression in a field where such expressions CANNOT normally be composed), but there MAY he good reasons that such functionality is not supported in the target field. (And, this workaround or hack MAY be prone to being “fixed”, so it’s potentially fragile.)

Do arithmetic for items from # selection

Ah! Ummm… I think I accidentally stumbled upon a workaround for that recently. (But I need to research to re-uncover what that was…) However, the “non-hacky” workaround is this: Presumably, API Workflows don’t need custom states as they have the database (perma-storage). So, in the workflow, you can create a new thing (of whatever type you need) and reference its unique ID (via “results of”) to delete it when done with it. Obviously this slows things down over temporary (in-memory) storage, b…

I’m sure there are more, but I’m tired of pasting.

[boston85719]

@keith

How many times have I noted that this is bad practice, as noted by Bubble? Lots.

I don’t know I don’t really pay too much attention to all of them, but I really appreciate the links to the ones you provided.

Do you have a count?