Journal posts have lost formatting

Splitting up the Gahnia Grove Post (2nd link) into separate posts

eg in restoration of much of the intended appearance

Update- have made some changes to the Final Report post and have restored bullet points, by replacing what looked in the Edit page like a bullet point (html? did I create these with a button in iNat?) with hyphen followed by space

in this combined Gahnia Grove journal post, the first point where formatting starts going awry is a spot where it looks like you’ve created an anchor point but have not closed it. add the close tag, and things from that point should look better:

for this journal, the first spot where formatting starts going off the rails is near the “NB Maximum” block. i think you’re intending this to be a second paragraph within the point #2, and i assume you’re trying to use markdown to achieve this, but i don’t think you can do this. try making the whole thing one paragraph instead of two paragraphs, and see if that fixes things. alternatively, make the second paragraph a sub-bullet by adding a couple of spaces at the front, and see what happens.

if there are still issues after editing that bullet, it would be helpful to see how you’ve drafted/coded the section between “Some locations are named…” and “The methodology’s attention to species identification…”. it looks like there may be multiple issues in how you’ve coded it, and it’s hard to see the full picture by just looking at the interpreted/resulting page.

a screenshot or two of what it looks like in Edit mode should be able to shed light on whatever the issue is in that section.

Thank you very much pisum. I have been working through the Gahnia Grove report with that info, closing anchors, and found a couple of unclosed italics, with much improvement. The paragraphs are the main thing still missing after this work.

When I have finished working through that report with what I have learned today I will address the other one, se what happens, and report back.

But first a cup of tea and a lie-down, and maybe another day or more, depending on external events, before I complete this.

Its not possible to screenshot it as it disappears when cursor moves off the button, but it seems to be a temporary thing usually followed by saving. Perhaps I unknowingly try to click it twice, due to the delayed response, and of course the 2nd try is refused.

It did not. I found a few invalid closing tags and fixed all that I found. The paragraphs are still missing in
Everything else is much improved, thank you pisum.
Starting work on the other one now.
Update: fiddled with those changes you suggested, not really important so I settled for combining sentences.
Any issues visible in this screenshot?

or the next bit? This is where problems escalate:

the interpreter that translates your edit text into html code is supposed to find paragraphs and add the proper <p> </p> tags before and after each of those blocks. it stops doing this in the middle of your journal post for some reason, and it’s not obvious to me based on your edit text why.

here’s what i would do to try to figure out where the problem exists…

the problem first manifests starting at the paragraph beginning “Unless otherwise noted Observations below are limited…” (i’ll call this paragraph A.) the problem ends after the paragraph that ends “… during the summer, with some unlikely to recover.” (i’ll call this paragraph Z.)

so i would manually add the <p> </p> tags to paragraph A and to paragraph Z. it should fix the formatting for at least paragraphs A and Z, but it may or may not fix the issue for paragraphs in between. if the formatting for paragraphs in between is not fixed, i would pick another paragraph about midway in between A and Z – i’ll call this J – and i would add the <p> </p> tags to J, and see if that fixes anything between A and J or between J and Z.

let me know when you’ve done this, and i’ll take another look at the journal to see if there are any new clues revealed.

I have done that. Eg para A

<p>Unless otherwise noted Observations below are limited to the defined Trial area, ie the banks below Kaipatiki Roadside, down to the stream and up the opposite bank to the forest path (“Native Plant Trail”).


One thought occurs to me: while proofreading and editing that report early last year I printed it out. I cant remember if I used another application to do that, perhaps copying the text into that application and copying it back. Word for Mac perhaps. Or using the webarchive app.

And now a para somewhere in the middle:

<p>Among the dead trees were 
- a majority of the observed tanekaha (see earlier reports)
- numerous mahoe at the pathside or within 2 metres
- several kanuka of only 20cm D or less, in locations of at least partial sunlight (and some larger, whose branches and foliage, in canopy breaks, appeared scant but could not be seen close enough to confirm life or death)
- a ti kouka 10-15mH below the roadside planted trees (Zone CaKRS).

hmmm… i’m not sure what to make of this. something similar to something described in a previous thread might be happening here, but i don’t see an obvious way to replicate the behavior here, and without messing around directly with your edit text, there’s no easy way for me to narrow things down much more on my end.

if you want to do further troubleshooting, you could do something similar to what you did with the Gahnia Grove journal post, breaking it up into multiple chunks to see how the individual chunks react. i would break this post up in the middle of the problematic section. so for example, if maybe for chunk 1, go from the beginning to what we were calling paragraph J, and then for chunk 2, go from paragraph J to the end. then based on what you see, do other variations to try to narrow down the issue.

other than that, it would take probably staff to get an exact copy of your edit text from the database (or by logging in as you) and then debug exactly what the code does when it gets to paragraph A.

Thanks pisum. It may need professional debugging, yes.

@tiwane Have been working on this, now republished: for 2 days now so it seems professional debugging may be required.

The only list used - or needed - is at the beginning, and it works ok, and pisum said it is correctly coded.

Bullet points are created unintentionally by my use of hyphen followed by space. I will have to add lines in places as the text is cramped, but the hyphen-space does not seem to be a problem. I tried removing all these and it didn’t restore the paragraphs.

I also added a backslash after the first numeral n each section number, ie 1:2 I changed to 1:2, in case that was a problem.

When I originally posted there were some bullet points in the Edit Text. These may have been imported by my copying and pasting some text at some point, and I had left them as they worked alright at that time. I removed them all and replaced each with hyphen-space.

I did ind a couple of missed a href closing tags, and corrected them.

If I split the post into sections I get correctly formatted sections, but when I combine them the paragraphs disappear again.

I still get the greyed out save button on my iMac sometimes when saving these test posts, but they do save.

Could there be a limit to post length which is affecting formatting or saving?

Or could my section names - ie 1:1, 1:2 etc - be a problem? There was another set of numbers in the original text, in the traditional system of 1. followed by 1.1, 12 etc, then 2, followed by 2,2 etc. I have removed these in case they were the problem.

I had used an asterisk in four places. After reading the Syntax guide I tried adding a backslash to these, but they appeared in published text so I removed both backslash and asterisks in case they were a problem.

The first section of the same text published separately has paragraphs correctly:

A later section
destroys paragraphs in other sections when added to them.

I am currently using Mohave 10.14.6 and Safari, but wrote the original text using an older machine and OS. After starting writing the report in the browser I could have copied the text to and from a text document for proofreading and editing…I forget.

based on some of these new examples, i’ve been able to reproduce at least one case where paragraphs are lost. basically, it looks like everything between 2 of the same kind of list (2 bulleted or 2 numbered, not 1 bulleted + 1 numbered) will lose paragraph formatting in between.


for easy reference, here’s some text that you can paste into a journal to start debugging with:

List 1
1. point 1
2. point 2

In between Paragraph 1

In between Paragraph 2 

In between Paragraph 3 

List 2
1. point 1
1. point 2

Extra paragraph 1

Extra paragraph 2

Extra paragraph 3

UPDATE: i looked at this a little more when i had a little more time, and the only workarounds i can think of are:

  1. limiting the number of lists in a given journal post. (at most, you can have a single bulleted list + a single numbered list.)
  2. forcing all affected paragraphs to h5 by using html tags <h5> </h5> or markdown prefix ##### . this isn’t technically correct since h5 is not equivalent to p, but they look the same or at least very similar in most cases.
  3. using a structure other than an actual list. you could accomplish the same thing as preformatted text or something like that, but it just won’t look as pretty as an actual list.

that said, given a journal post with multiple bulleted lists or multiple numbered lists, all paragraphs between the first and last such lists in a journal post will lack the proper paragraph formatting. this has to be resolved via a code fix, i think. so @tiwane and crew will probably need to take the ball at this point.

1 Like

Brilliant thanks pisum. That fits. I will give the workaround a go asap.

Should I actually try posting

this into the Journal? If so, what where? I am sorry but, as in the Syntax guide, its not clear to me which words are literally to be copied, or where.

this snippet is for someone to use to see the problem. it is not a means to work around the problem. you can try the workarounds i noted later, but they are all sort of ugly workarounds. the best solution will be some sort of change to the system’s code.

I see, thanks. Good to know I dont need to try to use the snippet.

I understand the workarounds are not a solution, and look forward to the bug being addressed.

So that was not meant for me, right?

right. that was meant for developers or anyone else interested in seeing how to reproduce the problem on their own.

one last thought: i’m not sure how much of a stickler the iNat staff abd forum moderators are in terms of thread classification, but this thread probably should be reclassified as a bug report rather than a general thread.

Yes. I debated which category to use for my OP, and decided to own the problem as an introduced coding error of my own, or the need to update my code to match website upgrade, and expected moderators to move it to Bug reports if discussion decided it was a bug.

This seems to be the case, thanks to your work pisum, so I provided my system details in a post above in preparation for debugging.

I think I have covered screenshots.
Since you seem to have confirmed the bug I dont think any more of my details are needed, but if there is anything else needed for debugging , @tiwane, please let me know.

Does this have to be done for each paragraph? If not, anyguide as to which ones?

And does the ##### prefix need a closing tag? Are the apostrophes part of the prefix? Should it be at the start of a paragraph?

I tried #####, with and without apostophe before and after, in a number of places including before and after bullet lists. It didnt help. I expect the symbol you used is not actually an apostrophe, and perhaps you used it to indicate preformatted text?

I have deleted earlier test reformatting copies and sections of the original post “Final Report”, and created 4 posts of sections 1 to 4. These, when combined in order, should replicate the original post.