ve3meo

Yes, thank you, David. Someone with more WP smarts than I has joined my site as co-Admin and wrote a plugin that queries the database and lists the hyperlinked sql files, links to the page or post to which each is attached along with the caption. I expect it could be readily modified to include the other file types.

Thanks for the response, David. It’s the subscriber’s view that is foremost. I’m not sure that Mime Type is appropriate or sufficient. I’d like for them to be able to filter on the extension.

It would be good if there was a MediaExt=sql,… parameter as an alternative to Mime Type. That would produce a better filtered list than MediaType=other, for our purpose.

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.

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.

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.

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, 1 month ago by ve3meo.

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 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?

For tags in pages to show in a tag cloud et al, you need a plugin that enables page tags to be treated as post tags. I’m still playing with this so I cannot recommend any but I am using “Category Tag Pages” plugin.

Good luck!

Tom

Are these in posts or pages?

By tags pane, do you mean the rendered Tags widget or the administrator view in the wp Dashboard?

That looks very helpful, David. I’m guessing that customising either wp-content/themes/sanse/functions.php or wp-includes.php/category-template.php to have a custom function leaves the former vulnerable to an update of the theme or the latter subjected by an update of wordpress. I have read something about creating a child of a theme for customisation so perhaps that would avoid the risk from an update of either the parent theme or the core. Perhaps another path would be a CRON job that would edit either of these files but that means I have to learn PHP and probably other things.

Thanks again!

Tom

I found the defaults for the wp_tag_cloud() function in wp-includes/category-template.php and changed the ‘number’ parameter from 45 to 100 and now get the bigger cloud of wiki_tags. That’s okay for now but I am guessing it won’t survive a wp update. I’m on 4.99.

Let’s call this topic resolved. The title has been met using Beaver Builder. For control of the quantity of tags in the user interface, I understand that is outside the purview of Yada Wiki as is the case for consolidating tags of different types.

With appreciation for your prompt and helpful response,

Tom

Hi David,

Thanks for the lead on Beaver Builder. I was able to put the wiki tag cloud on a page with that. Site building with WordPress is overwhelming, given the thousands of tools, options, themes. Now I have to find where the parameter is that limits the number of tags in the cloud to 45. Wikispaces allowed 100. I have about 150 and need to shrink the list but 45 is too constraining.

Cheers!
Tom

My script completed successfully and now there are Yada Wiki Tags matching the hashtags.

I guess the conclusion is that it would be nice to have support within the plug-in to handle custom post_type and related taxonomy. Perhaps in settings, a provision for the administrator to add a table of such pairs. Not knowing enough about wp, I don’t know if that is reasonable or if there is any demand for it.

Tom