Tag count not updated by Regenerate/

I may be mistaken that an Edit Update having made no changes was having any effect on the tag count or anything else. The additional hole or gap in the processing of hashtags in the Title is that the Posts or Pages list, the Edit, Quick Edit show no tag having been assigned, even though the rendered page or post has a valid hyperlink around the hashtag in the title. If I copy the hashtags from the title into the content or body, the hashtagger processing then does change these screens to show that the tags have been assigned. I can remove them from the content and the tags remain assigned – maybe that’s due to my option setting.

Having run into an “Invalid post type” error trying to bulk categorise Pages, I converted them all to Posts. So the same posts have been processed by Hashtagger as Pages and Posts with no apparent difference in behaviour for the list and edit screens.

Do you have any advice on what to look for, do?

OK, I’ve pretty well concluded that hashtagger doesn’t reliably, fully process hashtags in post titles, whether in Posts or Pages. But I have not found any pattern to it. I’ve Reset WP, re-imported HTML pages both with hashtagger active and inactive, Regnerated and I see mixed results in the admin’s listings of Posts or Pages, the Edit screen, Quick Edit screen and Bulk Edit screen. Some posts show tags have been assigned; others don’t. Yet the rendered pages have active links from the title hashtags to the tag archive page (is that the right term?) despite not being shown as assigned.

I’m stumped. Is hashtagger being thrown off by some content either in the title or body?

I think hashtagger is being thrown by some content in the body. It has to be smart enough to ignore the hash symbol when used inside a html tag but I think that smartness is flawed and is tripping it up on some of my imported pages. Here is the top part of a page or post that gives me a problem. The continuation has many hash symbols, e.g., <span style=”color: #ff0000;”> but that continued content by itself does not trip up hashtagger. Nor does the TOC at the beginning on its own cause the problem. It is the content that follows the TOC in this snippet that does and it does not even contain a #.

<div id="toc"><h1 class="nopad">Table of Contents</h1><div style="margin-left: 1em;"><a href="#Download unifuzz.dll">Download unifuzz.dll</a></div>
<div style="margin-left: 1em;"><a href="#Using unifuzz.dll with SQLite Expert">Using unifuzz.dll with SQLite Expert </a></div>
<div style="margin-left: 2em;"><a href="#Using unifuzz.dll with SQLite Expert-Version 3.5">Version 3.5</a></div>
<div style="margin-left: 2em;"><a href="#Using unifuzz.dll with SQLite Expert-Version 4 and 5">Version 4 and 5</a></div>
<div style="margin-left: 1em;"><a href="#Using unifuzz.dll with SQLite3.exe">Using unifuzz.dll with SQLite3.exe</a></div>
<div style="margin-left: 1em;"><a href="#Unifuzz.c Source">Unifuzz.c Source</a></div>
</div>
SQLite Expert now takes the lead as the most compatible with the RootsMagic RMNOCASE collation, thanks to the C extension <span style="line-height: 1.5;">unifuzz.dll authored or revised by Jean-Christophe Deschamps. Unifuzz can be used with other SQLite managers that support extensions, including the command-line shell sqlite3.exe but not, regrettably, SQLiteSpy. </span><br />
<br />
<span style="line-height: 1.5;">This is not simply a renamed equivalent of the SQLite NOCASE collation (see <a class="wiki_link” href="../RMNOCASE%20-%20faking%20it%20in%20SQLiteSpy">RMNOCASE - faking it in SQLiteSpy</a>); rather, it is a very comprehensive compilation of the unicode character set. Against a RootsMagic database comprising 8091 different Unicode characters in Surnames, PRAGMA Integrity_Check returns 187 missing rowids from indexes idxSurname and idxSurnameGiven with SQLite Expert using this substitute collation. SQLiteSpy returns 16042 missing rowids from the same two indexes including 9 from idxSourceTemplateName with its fake collation. RootsMagic itself reports two missing rowids from each of the two Person Name indexes so there is something wrong even with the genuine RMNOCASE collation.</span><br />
<h1 id="toc0"><a name="Download unifuzz.dll"></a><strong>Download unifuzz.dll</strong></h1>
 <span style="line-height: 1.5;"><a href="https://sqlitetoolsforrootsmagic.com/wp-content/uploads/2019/01/unifuzz.dll">unifuzz.dll</a> or <a href="https://sqlitetoolsforrootsmagic.com/wp-content/uploads/2019/01/unifuzz.dll.bak">unifuzz.dll.bak</a> (remove .bak extension after d/l, added due some systems' security)</span><br />
<span style="line-height: 1.5;">Download and save to the same folder where you have the executable file for SQLite Expert or the command-line shell (or other SQLite manager that supports C extensions).</span><br />
<h1 id="toc1"><a name="Using unifuzz.dll with SQLite Expert"></a><span style="line-height: 1.5;">Using unifuzz.dll with SQLite Expert </span></h1>
 <h2 id="toc2"><a name="Using unifuzz.dll with SQLite Expert-Version 3.5"></a><span style="line-height: 1.5;">Version 3.5</span></h2>
 <ol><li><span style="line-height: 1.5;">Under the menu item Tools > Options > Show/Hide Features, check the box labelled &quot;Load/Unload Extensions&quot; to reveal these selections in the File menu. The options is saved between sessions.</span></li><li><span style="line-height: 1.5;">To load the extension, simply select File > Load Extension and use the resulting &quot;</span>Select<span style="line-height: 1.5;"> extension file&quot; window to browse to, select and open unifuzz.dll. OK the default value &quot;sqlite_extension_init&quot; in the Entry Point window. That's it! You now have a very (if not perfectly) compatible RMNOCASE collation associated with the database.</span></li></ol><h2 id="toc3"><a name="Using unifuzz.dll with SQLite Expert-Version 4 and 5"></a><span style="line-height: 1.5;">Version 4 and 5</span></h2>
 The Show/Hide Features option is missing from this version as is File > Load Extension. The only choice is to right-click on the database name in the sidebar to invoke the drop-down menu which includes Load Extension and proceed as in step 2 for ver 3.5. 

• This reply was modified 6 years, 2 months ago by ve3meo.

Please don’t repeat messages… something about your posts is triggering the spam filters. Allow us some to to review/release them.

I’ve narrowed down the location of the trip-wire to this string:
<a class="wiki_link” href="../RMNOCASE%20-%20faking%20it%20in%20SQLiteSpy">RMNOCASE - faking it in SQLiteSpy</a>);
and further still to the “class=”. If this is the only content, hashtagger does not succeed:
<a class="wiki_link”>
nor this:
<a class="”>
but this succeeds:
<a>

So in my test file, I found two instances of
<a class="wiki_link” href="...
Deleting the first removed the trip-wire for hashtagger. I don’t know why the second is not an issue except it has a different class name:
<a class="wiki_link_ext"

I will have to look into whether this class is active and does anything useful. Unfortunately, that’s way down my learning curve – never did much with classes in anything. It comes over from the HTML and is defined in a CSS file. Not sure where that gets imported, if at all.

Well, that’s not a silver bullet. I used SQL to find all the posts with <a class=”wiki_link” in the content and there were only a handful, most of which had no hashtags in the title. There was only one that did and that had no registered tag visible in the Edit screen so it was fixed. Others I added hashtags to the title and hashtagger fully processed them. Go figure.

I still have a pile to sort out. Maybe the effort of manual tagging one by one will be less than trying to identify what all is tripping up hashtagger.

Found the silver bullet (or the trip-wire) and I blame it on Google Docs and my fuzzy eyesight. You can see it in my example”
<a class="”>
It’s obvious but I needed a magnifier to see it. The quotation marks are asymmetrical. The first is vanilla x22, the second is xe2 x80 x9d. It was only when using some software to search through my source files that translated the UTF-8 code for the closing quote to 3 characters that it jumped out to me.

Mea culpa, but Google Docs takes some of the blame. Months ago, I had worked out the pre-processing steps needed for a good HTML import of the content exported from Wikispaces. I ran an export from June through the steps and imported that into the prototype WP server. For repeatability, I logged the various Find/Replace terms in a Google Doc. I discovered back then that Docs was changing the second vanilla quotation mark of a pair to a closing quote and had to be careful when pasting the term into Notepad++ to correct this erroneous conversion.

Months passed and I processed a later export from Wikispaces following the steps in my Doc. But I missed a couple of things – one was that damned closing quote in the Replace term which effectively corrupted any hyperlink to another page on the site. And tripped up hashtagger. And has had me grinding away down wrong alleys.

Sorry for consuming all this bandwidth.