Problems with Error Checking AND Pinegrow rendering a HUGO site, both locally and via URL

[schpengle]

Hello.

Im not sure if I’m doing something wrong but I get this a lot when I use PG.

PG V 8.5 Mac.
Open URL.
PG says there are a pile of errors.

Create folder to save locally.

Check code, find errors, click button to refresh, check for errors.
ALL errors dissapear. including when I havent reallly done a lot.

this is the Yellow, box on RIght, number 1.

then, follow the advice of dialogue box to go
Page>Check for html errors and

Now pops up box number 2 in red on the left and…

ShaBaNg!

They all seem to be back again.

So which message is correct?
All errors gone,
Or
Pile of errros still there?

Clarification of my Query/report

Is the error checking actually checking the file Ive amended and saved edits too (of the URL, which Im using to style and check …things…like…for errors )

OR… is it simply reloading the URL when I click refresh and.. checking the RELOADED URL, and NOT the code I’m acutally looking at in the editor.. the code Im viewing/checking/fixing?

[schpengle]

Well, I’m unable to proceed with this much further atm.

the Page URL I’m looking at looks like this in my Browser (Brave, Chromium based)…

but when I open it in pinegrow it looks like this…

So Pinegrow is rendering the layout of that url incorrectly and loosing some styling (PINK "Blog*)

BUT.. RENDERS THE FONT CORRECTLY (Turnip)

Turnip

Now, Pinegrow is warning me of HTML errors, but , due to ISSUE 1 I posted above, wrt just what the heck is it error checking and what file is showing, and what is being saved… I dont know if thats an issue, but,

The cards are kind of stacked and have no bottom edges.

HOWEVER…

If I clone the URL of the site locally, using sitesucker

SiteSucker for macOS

and open the LOCAL copy of that web url, via a locally hosted server (Im using AMMPS)

AMPPS – WAMP, MAMP and LAMP Stack

and view it in Brave Browser,
It also renders fine as it should.

BUT its not rendering the Turnip font at all.

If I open that Same Locally saved clone of the url… in a PineGrow,
ITs once again BoRkEd.

BUT.. If i then open the LOCALLY cloned version, which renders perfectly in Brave browser (Chromium based) inside Pinegrow (8.5) . then use pinegrows OPEN IN BROWSER feature, to open up the local clone in Pinegrows own server…and view in Brave.. in the same browser but now on port 40000

its also BoRkEd!

So, in the same browser,
It also borked after opening via Pinegrows built in Server.

But renders fine if opened via a different localhost server

So, I dont know whats going on here exactly.

so same browser, but in pinegrow the view is broken, fonts are correct and when pinegrow renders it in the same browser which is rendering it perfectly well outside of Pinegrows influence its also broken, but again, fonts are correct.

and just to cheer you up,
This is what the site renders like when not run on a server and just viewed via the file system as

file:///Applications/AMPPS/www/cottonnoodle.com/index.html

lovely eh?
So Pinegrows not doing such a bad job but.. could do better or its the errors, but I cant use Pinegrow to fix them correctly due to the page check/error refresh loop.

So this is a site which The Author (not me) has created via the HUGO static site generator

The world's fastest framework for building websites

and the lady has posted info on how she has created the site, taxonomies etc , and Im using it to try and learn how to use Hugo and use Pinegrow for styling etc

BUT… here I am… on the Forum.
With an issue

so, suggestions?
What is going on with BOTH the rendering of the URL and Locally hosted site in Pinegrow, and HOW am I supposed to edit the URL files , saved locally in Pinegrow (apparently) as it didnt seem to be working correctly and was reverting to the original remote file, each time I clicked refresh after fixing errors… I THINK… as it would show NO ERRORS.

but, then when I clicked PAGE>Check for html errors. it was a collection of errors again, that looked the same/similar.

And just to be (as clear as Im led to believe) these are the output files AFTER hugo has done its thing. I think. There is obviously the need for a server to render the pages correctly, BUT I’m not sure what technologies that is yet.

Thanks.

UPDATE.
Now… it doesnt render the font correctly either.
ok im done with this for the day. well 2 days. in a heatwave

[schpengle]

Any feedback on whether I’m using the Open URL and editing/saving source code/styling correctly @Emmanuel or Should I report a bug.

[Emmanuel]

This is definitely a case that should be reported to support so it can be properly investigated.

[schpengle]

Ok thanks.
Well, I’ll leave the above posted as my bug report, as I will be basically repeating my self as that is the repeatable process with same result each time, if I was to contact support, and the above already took hours.

NOTE.
Pinegrow does throw a warning about a load of HTML errors in page, so that could be why its rendering it incorrectly (Or maybe correctly to Pinegrow if its adhering strictly to its inbuilt syntax checking rules, which I would understand -although the same leniency that the normal browser applies, in order to render the page correctly would be nice, ALONGSIDE the errors , or maybe an option to see both broken and lenient views of the page)

But, I cant check it in Pinegrow due to the fact I dont know whether its actually editing the errors and saving when Im working on the page, or just refreshing the url with each check and ignoring my saved local file - which I wouldnt of thought is the use case scenario for this.

But, if Im wrong, or not followed the correct procedure or explained something inchorently, let me know and I’ll do what I can to clarify.

[Emmanuel]

@schpengle

Or maybe correctly to Pinegrow if its adhering strictly to its inbuilt syntax checking rules, which I would understand -although the same leniency that the normal browser applies, in order to render the page correctly would be nice, ALONGSIDE the errors , or maybe an option to see both broken and lenient views of the page)

Pinegrow’s HTML parser is stricter than a browser to function correctly. This is an important part of how the app works.

Pinegrow doesn’t correct errors; it just highlights them when it detects them. The checking process isn’t perfect and might miss some errors, especially if there are a lot, which could impact how the app operates.

How to use valid W3C documents to maximize your experience with Pinegrow |...

[schpengle]

Well, that’s actually good to know, from the developing point of view.

Ive just run the site through the W3C html Parser and it gives this info

https://validator.w3.org/nu/?doc=https%3A%2F%2Fcottonnoodle.com

so that gives 15 errors

and pinegrow shows

which is 16 errors.

I get how one < out of sync can throw the whole shebang etc, so that could be the discrepancy.

ok ive found for instance the errors on this page seem to kick off with
span

which starts with </ span> on line 98

so starting with a closing tag isnt a winner really
but there are quite a few extra superfluous closing span tags after this!

but here in lies the problem with the Pinegrow Parser.

if you make code corrections
and just click save, then the parser error window with still show errors if they are there, or less errors if you have fixed something.

BUT…
once you remove JUST ONE of the error codes.
and click the orange

APPLY CHANGES button in the warning pop up,
the pinegrow parser window tells you that there are NO ERRORS.

Then Close project.
Open project and yet again, the errors (less of them if you corrected some code)
will show up - as they should!

But if you click the apply changes orange button, on just one error , it will tell you there are no errors on you page - even though there are.
It behaves differently to
SAVE after editing the code.

ive tried creating a Giphy screen capture of this process and, the file has dissapered somewhere and I’ve too much stuff to do , to carry on with this right now.

but that is the repeatable process

ironically on this URL , the W3C parser correctly identifies the initial error as

1. Error: Stray end tag span.From line 6, column 1328; to line 6, column 1334ight yarn.</span></li><
   (which is actually on line 98 in pg code editor)

and there are 5 of them!

Pinegrow Parser however doesnt even mention these until a few errors down the list.
see image above

so when trying to sift through them I struggled to make orderly sense of them.
The initial error of html should not contain div ul elements… well I have no idea about that!

[Emmanuel]

As I mentioned, error checking isn’t foolproof, and any errors left in the document can lead to unexpected behavior. Also, on pages with a lot of errors, I highly recommend editing externally (using Visual Studio Code and the extension recommended in the article I mentioned), then coming back to Pinegrow to edit the HTML documents once the errors are fixed.

[schpengle]

Well, I now have the page code down to one error and Pinegrow now renders it correctly.

but the behaviour of showing NO ERRORS after clicking the orange apply changes button AND the Proceed blue button, resulting in the refresh erros parser window seems to be not working, as it shows no errors when there are still a pile of them.

So the Pingrow process of
Orange Button - apply changes
Blue Button - Proceed.
Blue Button - Refresh (Parser window)

Ends in erroneous information that there are no errors.
thats a long process to get false information back.
It SEEMS thorough, but…

so this site is good for checking out the PG Open URL feature.

It appears PG IS actually saving my edits to a local file AND rendering correctly (albeit much more strictly than the browser - which is great as I wouldnt have noticed all the errors), but the HTML error parsing process and resulting window output of no errors isnt working correctly.

And thanks for the quick replies.
And yes, im using the outside checking tools, but the problem arose from pinegrow saying there were NO errors, when clearly there are.

Also, the errors it alerts to are pretty handy in that you click on them and it takes you to them .

BUT… if there are errors with regards to divs etc, and missing opening closing tags,
Then it can just take you to the very beginning of the code…with it ALL highlighted.

meh…!!
Not so useful

Ie, this site is missing the

</ main >

tag for instance!
and the extra FIVE < /span > tags right on earlier, really threw a spanner in the works.

Copy and paste and a static site generator… lesson learnt here.

[Emmanuel]

You’re absolutely right about the error detection system having some weaknesses, as I mentioned earlier.

Pinegrow’s error detection was primarily designed to catch errors when code is created from within Pinegrow - essentially for live editing scenarios. The system can get overwhelmed when importing documents that are already riddled with errors, like what you experienced with the missing <html> tag and multiple <head> tags.

The error detection becomes less reliable when dealing with heavily corrupted markup that wasn’t generated through Pinegrow’s visual tools. It’s more effective when you’re building incrementally and catching errors as they occur.

For the rest, the error detection is actually less crucial when you’re using Pinegrow’s built-in helpers like blocks, element libraries, and other integrated tools - since these generate clean, valid markup by design.

Your experience highlights an important point: when working with external content (especially from static site generators with copy-paste issues), it’s often better to rely on external validation tools alongside Pinegrow’s system rather than depending solely on the built-in error checker.

[schpengle]

Yes good points.

It does however, sort of make the whole Open from URL tool somewhat redundant in PG, if the error detection is basically only for PG Created content, yet is available in the open from URL process and I cant rely on it wrt editing the styles of those remote sites and then checking them out to see what they looked like and how they are (sometimes badly) structured .

As if the page has (or usually… I create).. Errors, then I cant actually use the whole multi button approach to check and rebuild the site and actually get consistent results.

Which was its really useful feature for styling choices, structure etc.

I bit of a shame really as its really useful in Pinegrow. TBH, its one of the features I used the most. To look at and inspect the internals of sites to work out how they tick.
So, finding the ability to actually use PG to find errors and fix and save those edits locally is a GREAT feature.

its just a pity that it doesn’t actually report the errors correctly.
Mainly this could become more robust in the future as Ive had the same results with local files ive, er, badly created before.

It would be great if this could be relied on in the future as I find debugging in PG great!
But I’ve now figured out the source of its limitations, but at least I now know that is actually saving the edits, its just a pity that it kind of falls over on this useful feature.

I mean i’ve got it down to ONE error now, and rendering mostly correct but its still the same, 3 button checking process to return a no errors report, which is..well, false.

Maybe it will become more robust/using different tooling in the future.
Or just loose the 3 button approach to get nowwhere fast.

Thanks for looking into this.
cheers!

N.B.

HALLELOOLYAH!

I’ve nailed it.
All errors now sorted.
Happy little dance.

I think Ill contact the author as I reallly REALLY like this page design and layout and it uses HUGO Static site Generator which I’d like to get to use.

And, what cheers me up is that the Site Author is a software Dev. So there is hope for me yet

[Emmanuel]

@schpengle

Mainly this could become more robust in the future as Ive had the same results with local files ive, er, badly created before.

Got it. Message received
I’m going to close this topic now because I believe we’ve covered everything.