inline sourcing errors today

Question

Help, today I'm getting errors for inline sourcing.  I place my source inline.  When I get to the next spot I need to use the source I get an error.

Here is what I'm doing <ref name="deed">'''Family Search Charleston South Carolina Deeds.... xxx</ref>  Then I copy the first part and place it at the next place I want to use the source, with the back slash in it like this <ref name="deed"/>.  I use this kind of sourcing all the time.  When I used this today I get errors.

Comments

Agreed, - I went off on a tangent here, and it's of no real relevance to the current discussion.

---

I am having the same problem.  Nothing to do with <br/>.  Nothing to do with <i> </i>.  And certainly nothing to do with spaces.  Something has changed in the software.

Can we get this fixed, please.

---

Maybe please give an example open profile where your problem occurs, David? This might help pin things down.

---

You need to remember wikitree'ers are amateur genealogists not coders. This should be flexible and easy at a basic level. If you know the fancy stuff then fine but if, like me, you just want to get a profile documented it shouldn't be so hard.

---

Ok.  Fair request.  98% of my profiles have the problem so I just assumed that everybody had 98% of their profiles not working correctly.  Try Dunn-16388 as an example.  It has always worked.  I went into edit mode, added a space, no other changes, save, got the error, chose 'save anyway' and it looks just fine.  'Save anyway' is the obvious workaround but should we have to be doing that?

Thanks for your help.

---

Thanks for the profile example, David. The FindaGrave reference on Dunn-16388 has two <BR> tags in it, so this is the same problem as previously reported.

---

Thanks Jim,

I am not sure quite what your comment means in terms of getting the problem resolved.  However, in one of the comments above you provided a link to a related discussion where I found the following comment

"It's the "<br />"s in the reference. We will work on getting it fixed. commented 2 days ago by Jamie Nelson"

So I assume that we can sit back and patiently wait  and it will get fixed and we will no longer get this error on profiles with <BR> or <br/> in them.

---

---

Please see the comment I added to my answer below.  I believe it fully clarifies everything above that has been said about me and what I have previously written in G2G on this topic, as well as provides the current space vs no space before the "/>" requirement for empty tags.

---

Same with me, Michelle. I've been doing these for ever and all of a sudden yesterday the errors started popping up. Man, I hope these don't show up in my suggestions

---

Yes, David, you are right: the problem is being worked on (though I've suggested an alternative interim approach for the Team to consider in another comment). The issue affects not only br but any recommended tag which might appear inside a ref: hidden comment, blockquote, sub, sup and nowiki (see under Angle Brackets at this link), perhaps plus del which Leif mentioned and could arguably be added to the recommended list.

Answer 1

Yes, thanks Jim. I have used the <i> tag for a lot of profiles lately and the fact that it is in error has just cropped up.

I have also been pulled up for having an email address in a source. Usually these get deleted on editing the gedcom but that caught me by surprise.

The other issue I just had is not being able to save an edit when adding my gedcom sources to an existing profile. The existing profile had children born after his death. I could not remove the children until I saved and I could not save. In the end I had to input a false death, save then reopen to remove the incorrect children.

Clearly the original profile had been created like this without raising any red flags so I think this is part of the update too.

Comments

Thanks Philip. I'm afraid I think it might have saved a lot of trouble if there had been notice of this batch of software updates with details of the changes, preferably in advance so we would have had an idea what to expect and watch out for. If there was an announcement in this case, I missed it.

---

Jim, a related question. So far I have about 120 new profiles, all with the dreaded<i> etc tags. Is there a way to do a search and replace in the wiki editor or should I copy the test out to an external editor then paste back in? The Wiki editing tools seem pretty limited.

PS. I would never knock the coders on Wikitree, they are why it works as well as it does :-)

---

Good question, Philip. You might discover that when you have the edit tab open, your browser's find-in-page or control-F function will help you to find instances of i> for example (covering both <i> and </i>). But then you would have to replace them manually, because the wiki editor does not have a search and replace function. On balance using an external editor may be the best approach.

---

Exactly.

I have tried a couple of pasting to TextEdit on my iMac and found it really trivial to do.

I know TextEdit is not the fanciest editor out there but it works fine for this and I already have it.

Thanks

Answer 2

Yesterday, an error popped up where I was editing a profile with <ref name="X"/> before the citation <ref name="X">Test.</ref>. I was able to "Save anyway". The order doesn't seem to matter and AFAICT, the error was caused by having <X@xmail.xom> in the reference. Changing to square brackets fixed the problem Change Details for Fox-1372 (wikitree.com)

Comments

Interesting example, Aaron. I wonder now if any appearance of < and/or > between <ref> and </ref> triggers the new problem, even though it was accepted before the software changed.

---

Yes, it seems reasonable that the occurence of <'s an >'s inside a reference can be difficult to parse, but it has obviously worked before.

It's easy to say that you shouldn't use raw HTML inside a reference, and for things like bold and italics it can be easily avoided. But for my own part, I'm occasionally using the <del></del> tags to strike out a name entered in error and corrected, because the erroneous name can give additional clues. I haven't found a way to produce strikeout in Wiki code.

Answer 3

It seems to me that if software changes cause previously good code to no longer work then it would be appropriate to set a bot to make whatever changes are necessary to correct pre-existing - and previously good - code, rather than leaving profiles with errors that are not found until someone tries to edit them.

PS - in response to Philip's comment - not all WikiTreers fit that description.  I happen to be an even-less-than-amateur genealogist but literally a professional coder.  That said, your point is well taken for probably the great majority of WikiTreer's.

Comments

I just saw that I have been referenced as some sort of code authority (THANX for the compliment Melanie, but any claims I might make to authority are purely bogus).  At any rate, I will attempt to respond.  First, as to the question of whether I provided a reference for stating that the space before the "/>" is required - I would have been quoting the HTML 4.0 standard.  Although I could provide a link to it here, I am not doing that because it has been replaced by HTML 5.0.  I had not studied HTML 5 in depth before, but went to look up the reference there and discovered that HTML 5 no longer requires the space.  Whether or not the space is to be used is a function of something called the DOCTYPE, which is the declaration made in the first line of the file that designates the specification to be used to parse (fancy-shmancy for formatting the document for browser display) the file.  We used to use the version number - (as in HTML3 or HTML4, etc) but HTML5 uses just plain HTML without any version number.

Although it may be addressed in the HTML5 Specification, I did not find it on a quick search.  I did find something VERY interesting, though, HERE, where several different markup languages are explained.  It explains void elements (ones that do not operate on content and therefore don't have start and end tags) with an example of a tag that creates a button as follows:

To create a button with the input element, do this if you use an XHTML doctype:

<input type="submit" value="Ok" />

And this if you use HTML:

<input type="submit" value="Ok">

Both are ok if you use HTML5.

Bottom line:  It looks like the pendulum has swung and in HTML5, empty tags are shown with and without the slash, but when the slash is used it is shown with the space before it.  It should be noted, though, that the coding we do here is not HTML-anything.  It is wikicode, which is a crudely bastardized version (in my opinion) of a very old HTML version.  WikiTree uses the WikiMedia  parser (and they use an out of date version of that) to convert wikicode to XHTML 1.0 code to be displayed in our browsers.  Thus, according to the above, we SHOULD be using the space!

For anyone interested, if you use your browser's "View Source" function (you can probably right click and select it in most browsers) when you are on a WikiTree page (not a G2G page), you will see the following first line:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

---

You'll always be my code guru! 
(I was going through all the emails from you where you very patiently explained code and why we do (or should do) what we do.  There were a lot of them!  )

---

Gaile, thank you for the history. But the version of the WikiMedia parser software in use at WikiTree is clearly coded to accept either a space or no space before the closing slash, because by experiment both work. Therefore it is not correct in practice (as opposed to theory) to say WikiTreers "should" use a space: it doesn't make any difference whether we do or not, and as I said before the question is a red herring.

On the actual problem, if it is difficult and will take time to modify the new code so that it both does the extra check and (as the old code did) accepts < and > inside <ref>...</ref>, then it would be worth considering reverting to the old code in the meantime, since so many profiles and WikiTreers are being affected.

---

Arggh. I constantly use Rob Pavey's WikiTree Sourcer to create references, but only just now added my first named reference in a few days. Of course my citations are riddled with single line breaks, for which mediawiki always uses <br /> I was hoping it would be as simple as adding that space before the slash as mediawiki recommends, but I'm late to the complaining party.

I wonder how much trouble I'll get in by becoming accustomed to clicking "save anyway" until we get the fix...

---

Karen, this isn't my idea of a good fix, or even something that we should ever have to do to accomodate unreasonable software changes that do not elegantly handle legacy constructs, but just a suggestion if you want to avoid using code elements inside ref's (for what it's worth, I refuse to stoop to doing this - I will continue to use code elements inside ref's).  If you use a colon, it will indent your lines but each colon will give you a new line, at least.

---

Thanks, yes, that would certainly do it. I'm a long-time mediawiki editor and software engineer myself. I'll just click "save anyway" until the fix comes along.

Answer 4

I had the same problem today. I just went back and checked everything, deleted and retyped the same stuff and the error went away. I don't know why it was doing that but it fixed itself.

Answer 5

I struggle through the coding needed to make nice profiles and I've run across this problem today, also. I narrowed it down to the use of italics <i>xx</i>, but it did allow me to save anyway. See Pabst-387. I tried using a space before the /, but that didn't work, either. I am not quite following this discussion, is this a glitch that will be fixed? Can I ignore the problem since I was able to save the profile regardless? Or will I encounter problems down the road if I don't remove the italics? Thanks for any feedback.

Comments

It is a glitch that is being worked on.  Various screams are being posted on G2G, should you wish to read them.

---

I narrowed it down to the use of italics <i>xx</i>, 

answered by Jane Alexander

-

Swap out those <i> and </i> for '' (that's two apostrophes - aka single straight quotes, not a double " quote) as the html should not be being used.

---

Melanie, I don't quite understand. Can you provide an example? Am I using the <i> </i> incorrectly? Thanks.

---

Basically, you should not be using <i> at all.  It is html, not wikitext markup.

https://www.wikitree.com/wiki/Help:HTML_and_Inline_CSS

---

Oh boy. Just when I thought I sort of understood things. Thanks for the link, I'll see if I can figure it out.

---

The italics are actually very easy to apply.  In edit mode you should see some "buttons" just above the text box (if they show up in this comment - otherwise I'll be back with a screencap) --

The second one from the left is the italics.  Just highlight the text you want italicised, and click that button.  Bingo!  You have your text in italics. 

---

Thank you! I just edited my profile and it worked great, you are right, it is easy. I admit I sometimes get so overwhelmed by all the features on WikiTree that I have stopped paying attention to a lot of it. My mistake!

Answer 6

This should be fixed now :)