<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body>A new request with request id 6569 has been created by koha-devel-request@lists.koha-community.org. Short info on the request is : <br><br>Title : Koha-devel Digest, Vol 203, Issue 16<br>Category : <br>Description : <div>Send Koha-devel mailing list submissions to<br> koha-devel@lists.koha-community.org<br><br>To subscribe or unsubscribe via the World Wide Web, visit<br> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br>or, via email, send a message with subject or body 'help' to<br> koha-devel-request@lists.koha-community.org<br><br>You can reach the person managing the list at<br> koha-devel-owner@lists.koha-community.org<br><br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of Koha-devel digest..."<br><br><br>Today's Topics:<br><br> 1. Koha Wiki migrated and upgraded (Thomas Dukleth)<br> 2. Re: Koha Wiki migrated and upgraded (Tomas Cohen Arazi)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Thu, 27 Oct 2022 12:29:19 -0000<br>From: "Thomas Dukleth" <kohadevel@agogme.com><br>To: "koha-devel" <koha-devel@lists.koha-community.org><br>Subject: [Koha-devel] Koha Wiki migrated and upgraded<br>Message-ID:<br> <d0bfc78d73804416ab0f74bc9540e69e.squirrel@wmail.agogme.com><br>Content-Type: text/plain;charset=utf-8<br><br>[For those not subscribed or giving attention to the Koha mailing list, I<br>repeat the announcement here without in message cross-posting.]<br><br>The Koha Wiki now running MediaWiki Canasta has been up for a few hours at<br>the usual DNS subdomain https://wiki.test.koha-community.org . The wiki<br>is now up to date with MediaWiki 1.35.07 long term stable using a MySQL<br>database and ElasticSearch with many fine enhancements such as<br>xVisualEditor, customised AdvancedSearch, and dynamic archiving of<br>obsolete pages (which often still have useful information). Please see<br>further below for details.<br><br>Unfortunately, the mail system on the server for the wiki for resetting<br>wiki login passwords, or creating new login users, etc. had previously<br>become broken and was missed for fixing amidst all the work which people<br>have been doing for releasing a new Koha version. Someone will send a<br>message when the mail system is fixed. If you know your Koha wiki login<br>username and password from previously, they will work.<br><br>There are problably many problems with result set relvance for search<br>queries within the wiki. We will fix them over time and relevance ranking<br>should automatically improve with use, although, maintenance changes may<br>often count as use eroding recently updated relevance. The wiki is now<br>using ElasticSearch which is used by Wikipedia and has better extension<br>support than database based indexing. See some details about the<br>customised AdvancedSearch and the need for careful consideration in<br>improving search query indexing further below.<br><br>Sitemap creation, which assists Google and other web indexing systems in<br>indexing the Koha wiki, may not be working correctly in the way in which<br>we have configured the MediaWiki Canasta Docker container. Google and<br>others can still index the content without the sitemap but the process<br>functions better with a sitemap. The Canasta Docker container does some<br>things differently than the way they would function in a standard<br>environment such that less effort should be required for maintenance tasks<br>but we need a little more time to examine how some things such as sitemap<br>creation are intended to function in Canasta. We should always be able to<br>use methods ordinarily used for sitemap creation in a standard environment<br>if necessary.<br><br>The Koha MediaWiki Canasta test instance should continue to be available<br>for first testing significant changes and bug fixes, at<br>https://wiki.test.koha-community.org . Please do not make wiki<br>contributions that you want to save in the MediaWiki Canasta test instance<br>as they will not be carried over to the production wiki. Continue to make<br>lasting contributions to the production wiki at<br>https://wiki.koha-community.org .<br><br>Please read below for an understanding of what to expect before reporting<br>issues about which we are already aware, such as the test database is not<br>a current copy of the wiki and the mail system for resetting login<br>passwords and creating new login users is not working.<br><br>You may report bugs to the bug "wiki needs updating to a later version",<br>https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23073 .<br><br>WIKI DATABASE MIGRATION, UPGRADE, AND CONTAINER MANAGEMENT.<br><br>Migrating the Koha MediaWiki database from Postgres to MySQL and upgrading<br>to MediaWiki 1.35.07, the current long term stable version used a<br>repeatable process managed with a set of scripts which I developed in<br>bash, Perl, and Python as appropriate for the task and previous code in<br>the case of Python. Choosing Postgres as the database for a test instance<br>for MediaWiki had left us with a mistake in database choice complicating<br>compatibility and future upgrades when the MediaWiki test suddenly became<br>the only Koha wiki running when the previous Koha wiki went down in the<br>midst of a community schism with LibLime long ago. The database migration<br>and upgrade process has been developed and progressively tested over the<br>course over time from 2019 for ensuring that the database is migrated<br>correctly, etc. I built the database migration process upon the<br>originally incomplete and sometimes mistaken Python script of Philipp<br>Spitzer which was a fantastic proven starting point without which the task<br>may have been some degree too much.<br><br>Mason James ran a web crawl and diff test to verify that the production<br>and another test database migration and upgrade of the wiki had the same<br>content except for evident changes where the production wiki had been<br>updated with new content.<br><br>The database was imported to MediaWiki Canasta which Tomás Cohen Arazi<br>identified and customised to connect to the Koha Portainer Docker<br>container management to provide MediaWiki in a Docker container with a<br>large set of important extensions to help make managing the MediaWiki<br>software easier. See https://github.com/CanastaWiki for more about<br>MediaWiki Canasta.<br><br>After a minimial final testing period with Canasta in Koha Portainer, I<br>marked the old wiki instance which had been using Postgres readonly and<br>proceded with the database migration and upgrade using an up to date copy<br>of the database. Tomás made further modifications in Portainer and Chris<br>Cormack redirected the DNS record for wiki.koha-community.org DNS to the<br>current server for the wiki.<br><br>Although you may never notice an interruption in service for the wiki. We<br>may have to restart it to fix things which function a little differently<br>and a little more complicated to fix for the MediaWiki Canasta Docker<br>container than a standard operating system environment. Once fixed,<br>maintenance of a Docker container should be easier than a standard<br>environment. We may even move the server or some functions back to the<br>server where the wiki had been hosted for years thanks to Galen Charleton<br>and Equinox.<br><br>See further below for a little about other modifications which I made to<br>support dynamic archiving, etc.<br><br>KNOWN ISSUES.<br><br>The mail system on the server for the wiki for resetting wiki login<br>passwords, or creating new logins, etc. had previously become broken and<br>needs fixing as a matter of priority.<br><br>The test instance at https://wiki.test.koha-community.org has copy of the<br>database which will become outdated over time. In future, we may set up a<br>process to update the database periodically. The purpose of the test<br>instance is to support testing significant wiki changes or wiki bug fixes<br>first without the hazard of harming the production wiki. Bug fixes need<br>testing and can at least temporarily break the wiki. Significant changes<br>may fail to work as expected and might not be easily undone particularly<br>if the changes have been created by a script for mass editing. Having the<br>latest wiki revisions is not usually needed for testing.<br><br>There have been bugs specific to MediaWiki Canasta rearranging some<br>standard files for the Docker container which have been addressed. <br>However, there are at least some Canasta Docker specific bugs relating to<br>the Docker container environment. Please report any instances of "Error<br>creating thumbnail: Unable to save thumbnail to destination" which I found<br>in the Koha History page https://wiki.koha-community.org/wiki/History . <br>Instances of the bug can be fixed with command line shell access by<br>removing the images/thumb/$buggy_image_name subdirectory for the image and<br>making non-changing edit to the page which allows MediaWiki to recreate<br>the images/thumb subdirectory without a problem and the bug goes away. We<br>should probably remove all the subdirectories in the images/thumb<br>directory proactively. Yet, why is there a special problem for the Docker<br>container which does not exist in other test instances when not using a<br>Docker container and the container environment is running as the root user<br>as standard for Docker containers and the root user should have all the<br>permission necessary to access or create a thumbnail directory? Changing<br>the ownership of the images directory and subdirectories back and forth to<br>test the effect temporarily broke a test instance of the wiki until the<br>container was restarted.<br><br>MAJOR ENHANCEMENTS FROM UPGRADING.<br><br>The VisualEditor extension used by Wikipedia is a WYSIWIG and guided forms<br>aid for visually editing the underlying wikitext for a page and using<br>guided forms for adding some features to a page. Users can switch back<br>and forth between source editing in all wikitext syntax and VisualEditor,<br>however, it may be best to save the current edit before switching back and<br>forth to avoid problems of imperfect correspondence between wikitext<br>syntax and the VisualEditor model of wikitext.<br><br>The AdvancedSearch extension used by Wikipedia is helpful for a user<br>friendly interface to construct search queries and modify them by removing<br>terms which appear in a bubble with an [x] to remove the term. <br>AdvancedSearch depends on ElasticSearch which performs remarkably well in<br>testing and allows the wiki to be reindexed in a couple of minutes if<br>necessary. See further below for modifications to the AdvancedSearch<br>extension.<br><br>SemanticMediaWiki was reinstalled after copying the upgraded database. <br>Modifying the AdvancedSearch extension in conjunction with special<br>AdvancedSearch navigation links and custom queries using carefully managed<br>standard wiki categories may be more helpful than SemanticMediaWiki. <br>Furthermore, anyone experimenting with SemanticMediaWiki should be aware<br>that verbose syntax is required to avoid breaking most wikis with<br>SemanticMediaWiki after forthcoming MediaWiki updates in which a hook<br>commonly relied upon for SemanticMediaWiki which has been deprecated will<br>be removed. Wikipedia does not use SemanticMediaWiki and thus some<br>MediaWiki developers may not have given sufficient consideration to<br>managing the issue. The workaround may involve a potential performance<br>deficit when using SemanticMediaWiki search queries.<br><br>The MassEditRegex extension has power one might hope for in the name for<br>using regular expressions to modify a list of pages. However, given its<br>power it remains commented out in LocalSettings.php for the production<br>system. Use is intended to be for some special group of users such as<br>wiki administrors, however even they should be most strongly cautioned to<br>first test their process on a test instance of the wiki. Furthermore, use<br>should be with a bot subaccount set up by the user so that they may be<br>identified as the work of a bot process and those mass changes may avoid<br>adversely affecting page modification priorities in search result sets. <br>The creation of user bot subaccounts should be documented. In testing,<br>MassEditRegex works fantastically well for adding categories to the bottom<br>of pages and templates to the top of pages which can be done without risk<br>of an inadequately debugged regular expression breaking page content in<br>the middle.<br><br>MODIFIED FEATURES.<br><br>I modified the following to support dynamic archiving in which obsolete<br>content does not appear by default for search results unless the user goes<br>directly to the advanced search page without following provided navigation<br>links or changes the default VectorMod skin affecting the basic search<br>box.<br><br>ADVANCEDSEARCH EXTENSION WITH MODIFICATIONS.<br><br>The AdvancedSearch extension has been modified to include two additional<br>form elements: one for excluding particular categories and another for<br>excluding particular templates. These additional elements appear in the<br>user friendly AdvancedSearch term bubbles which can be individually<br>removed from a query by clicking on the [x] for the particular bubble.<br><br>Editing the non-English localisation files is still pending. For<br>languages for which a non-English localisation file has not been edited,<br>the custom fields for category and template exclusion display a<br>description in English.<br><br>DeepCategory searches for subcategories of a category is disabled because<br>it requires a sparkle database and is only updated on a weekly basis for<br>Wikipedia. Searching subcategories of a category should be less of an<br>issue with faceted use of categories which we should be carefully moving<br>towards.<br><br>Excluding particular categories supports dynamic archiving by supporting<br>search queries excluding obsolete pages with -incategory:"Obsolete", which<br>is automatically invoked from the navigation link "Advanced Search<br>current" or from simple search box when using the modified Vector skin,<br>VectorMod. Obsolete pages are also noted with a prominent notice using<br>the Obsolete template. Such pages should be updated if they can be, but<br>are otherwise available to consult most importantly for valuable<br>information they often contain which is not yet present in current pages. <br>Archived obsolete pages can be found exclusively by following the<br>navigation link<br>"Advanced search obsolete archive" which includes incategory:"Obsolete"<br>automatically.<br><br>The result set for search queries with incategory:"Obsolete" can be used<br>to identify the type of pages which should have the Obsolete category and<br>Obsolete template but do not yet, such as installation information for<br>some particular old Debian versions. Various combinations of including<br>and excluding categories and templates can be easily used in the modified<br>AdvancedSearch to find pages which only have one of either the Obsolete<br>category or Obsolete template which should be used together or both<br>removed if the page has been updated to be current.<br><br>All wiki pages should have some category even if it may be<br>[[Category:Empty]] for people uncertain of what may be appropriate in the<br>moment. Pages missing categories may not be disappearing from query<br>results by category when using ElasticSearch indexing as they had been<br>when using database based search indexing. We can also query for pages<br>missing categories using<br>https://wiki.koha-community.org/w/index.php?title=Special:UncategorizedPages<br>and correct the issue which has been neglected due to loss of time where<br>migrating and upgrading the wiki has been the priority with much less time<br>available otherwise especially since the pandemic.<br><br>We should take some care when thinking about faceted category use as no<br>wiki software uses fielded categories. Thus there may be no concise way<br>to query for pages which address a topic in a general way or supplement<br>other documentation on a topic containing a lone category such as<br>[[Category:Circulation]], if we then have many other pages with<br>[[Category:RFCs]] and [[Category:Circulation]] but no longer<br>[[Category:Circulation RFCs]] as a possible change for faceting. In such<br>an example, the search results of a query for incategory:"Circulation"<br>might have a result set in which pages for RFCs relating to circulation<br>issues containing both [[Category:RFCs]] and [[Category:Circulation]]<br>might crowd out more generally helpful pages with [[Category:Circulation]]<br>alone. The problem may indicate a need for a navigation link to exclude<br>RFCs from a search query; designating old RFCs as obsolete; or both. <br>Alternatively or additionally, we may be able to adjust the weighting of<br>the ElasticSearch indexing options such that pages containing<br>[[Category:RFCs]] have a lower weight and appear further down the result<br>set or pages with a single category such as [[Category:Circulation]] alone<br>or some particular additional categories such as<br>[[Category:Documentation]] have higher weight and appear further up the<br>result set.<br><br>VECTORMOD SKIN.<br><br>Users are free to choose their own preferred MediaWiki skin and we can add<br>others. VectorMod is merely set as the default to help people avoid<br>obsolete pages when submitting search queries from the simple search box<br>which appears on every page.<br><br>VectorMod is a custom version of the Vector skin which includes a modified<br>version of Vector/includes/templates/SearchBox.mustache supporting dynamic<br>archiving of obsolete content by excluding pages which have been<br>designated obsolete by automatically adding -inCategory:"Obsolete" to<br>basic search querries. The syntax incategory requires using<br>ElasticSearch. Previously, I replaced the SearchBox.mustache file in the<br>Vector skin<br>directly, which certainly worked without the extra effort of creating a<br>custom skin.<br><br>Automatically inserting -inCategory:"Obsolete" in the basic search box is<br>now somewhat elegant in conjunction with the modified AvancedSearch<br>extension as it uses explanatory language labels with a bubble which has a<br>removal [x] and allows autocompletion of query terms.<br><br>Significant renaming of references to Vector as VectorMod and vector as<br>vectormod has been scripted allows both Vector and VectorMod to be loaded<br>and available to users.<br><br><br>Thomas Dukleth<br>Agogme<br>109 E 9th Street, 3D<br>New York, NY 10003<br>USA<br>http://www.agogme.com<br>+1 212-674-3783<br><br><br><br><br>------------------------------<br><br>Message: 2<br>Date: Thu, 27 Oct 2022 10:07:49 -0300<br>From: Tomas Cohen Arazi <tomascohen@gmail.com><br>To: Thomas Dukleth <kohadevel@agogme.com><br>Cc: koha-devel <koha-devel@lists.koha-community.org><br>Subject: Re: [Koha-devel] Koha Wiki migrated and upgraded<br>Message-ID:<br> <CABZfb=WsZShQAdBHkV=wG0xYXD=u1b6n7cJr88U+nrpPwi=zGw@mail.gmail.com><br>Content-Type: text/plain; charset="utf-8"<br><br>Excellent work Thomas!<br><br>Congratulations for getting it done so well.<br><br>Thanks!!!<br><br>El jue, 27 oct 2022 a las 9:29, Thomas Dukleth (<kohadevel@agogme.com>)<br>escribió:<br><br>> [For those not subscribed or giving attention to the Koha mailing list, I<br>> repeat the announcement here without in message cross-posting.]<br>><br>> The Koha Wiki now running MediaWiki Canasta has been up for a few hours at<br>> the usual DNS subdomain https://wiki.test.koha-community.org . The wiki<br>> is now up to date with MediaWiki 1.35.07 long term stable using a MySQL<br>> database and ElasticSearch with many fine enhancements such as<br>> xVisualEditor, customised AdvancedSearch, and dynamic archiving of<br>> obsolete pages (which often still have useful information). Please see<br>> further below for details.<br>><br>> Unfortunately, the mail system on the server for the wiki for resetting<br>> wiki login passwords, or creating new login users, etc. had previously<br>> become broken and was missed for fixing amidst all the work which people<br>> have been doing for releasing a new Koha version. Someone will send a<br>> message when the mail system is fixed. If you know your Koha wiki login<br>> username and password from previously, they will work.<br>><br>> There are problably many problems with result set relvance for search<br>> queries within the wiki. We will fix them over time and relevance ranking<br>> should automatically improve with use, although, maintenance changes may<br>> often count as use eroding recently updated relevance. The wiki is now<br>> using ElasticSearch which is used by Wikipedia and has better extension<br>> support than database based indexing. See some details about the<br>> customised AdvancedSearch and the need for careful consideration in<br>> improving search query indexing further below.<br>><br>> Sitemap creation, which assists Google and other web indexing systems in<br>> indexing the Koha wiki, may not be working correctly in the way in which<br>> we have configured the MediaWiki Canasta Docker container. Google and<br>> others can still index the content without the sitemap but the process<br>> functions better with a sitemap. The Canasta Docker container does some<br>> things differently than the way they would function in a standard<br>> environment such that less effort should be required for maintenance tasks<br>> but we need a little more time to examine how some things such as sitemap<br>> creation are intended to function in Canasta. We should always be able to<br>> use methods ordinarily used for sitemap creation in a standard environment<br>> if necessary.<br>><br>> The Koha MediaWiki Canasta test instance should continue to be available<br>> for first testing significant changes and bug fixes, at<br>> https://wiki.test.koha-community.org . Please do not make wiki<br>> contributions that you want to save in the MediaWiki Canasta test instance<br>> as they will not be carried over to the production wiki. Continue to make<br>> lasting contributions to the production wiki at<br>> https://wiki.koha-community.org .<br>><br>> Please read below for an understanding of what to expect before reporting<br>> issues about which we are already aware, such as the test database is not<br>> a current copy of the wiki and the mail system for resetting login<br>> passwords and creating new login users is not working.<br>><br>> You may report bugs to the bug "wiki needs updating to a later version",<br>> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23073 .<br>><br>> WIKI DATABASE MIGRATION, UPGRADE, AND CONTAINER MANAGEMENT.<br>><br>> Migrating the Koha MediaWiki database from Postgres to MySQL and upgrading<br>> to MediaWiki 1.35.07, the current long term stable version used a<br>> repeatable process managed with a set of scripts which I developed in<br>> bash, Perl, and Python as appropriate for the task and previous code in<br>> the case of Python. Choosing Postgres as the database for a test instance<br>> for MediaWiki had left us with a mistake in database choice complicating<br>> compatibility and future upgrades when the MediaWiki test suddenly became<br>> the only Koha wiki running when the previous Koha wiki went down in the<br>> midst of a community schism with LibLime long ago. The database migration<br>> and upgrade process has been developed and progressively tested over the<br>> course over time from 2019 for ensuring that the database is migrated<br>> correctly, etc. I built the database migration process upon the<br>> originally incomplete and sometimes mistaken Python script of Philipp<br>> Spitzer which was a fantastic proven starting point without which the task<br>> may have been some degree too much.<br>><br>> Mason James ran a web crawl and diff test to verify that the production<br>> and another test database migration and upgrade of the wiki had the same<br>> content except for evident changes where the production wiki had been<br>> updated with new content.<br>><br>> The database was imported to MediaWiki Canasta which Tomás Cohen Arazi<br>> identified and customised to connect to the Koha Portainer Docker<br>> container management to provide MediaWiki in a Docker container with a<br>> large set of important extensions to help make managing the MediaWiki<br>> software easier. See https://github.com/CanastaWiki for more about<br>> MediaWiki Canasta.<br>><br>> After a minimial final testing period with Canasta in Koha Portainer, I<br>> marked the old wiki instance which had been using Postgres readonly and<br>> proceded with the database migration and upgrade using an up to date copy<br>> of the database. Tomás made further modifications in Portainer and Chris<br>> Cormack redirected the DNS record for wiki.koha-community.org DNS to the<br>> current server for the wiki.<br>><br>> Although you may never notice an interruption in service for the wiki. We<br>> may have to restart it to fix things which function a little differently<br>> and a little more complicated to fix for the MediaWiki Canasta Docker<br>> container than a standard operating system environment. Once fixed,<br>> maintenance of a Docker container should be easier than a standard<br>> environment. We may even move the server or some functions back to the<br>> server where the wiki had been hosted for years thanks to Galen Charleton<br>> and Equinox.<br>><br>> See further below for a little about other modifications which I made to<br>> support dynamic archiving, etc.<br>><br>> KNOWN ISSUES.<br>><br>> The mail system on the server for the wiki for resetting wiki login<br>> passwords, or creating new logins, etc. had previously become broken and<br>> needs fixing as a matter of priority.<br>><br>> The test instance at https://wiki.test.koha-community.org has copy of the<br>> database which will become outdated over time. In future, we may set up a<br>> process to update the database periodically. The purpose of the test<br>> instance is to support testing significant wiki changes or wiki bug fixes<br>> first without the hazard of harming the production wiki. Bug fixes need<br>> testing and can at least temporarily break the wiki. Significant changes<br>> may fail to work as expected and might not be easily undone particularly<br>> if the changes have been created by a script for mass editing. Having the<br>> latest wiki revisions is not usually needed for testing.<br>><br>> There have been bugs specific to MediaWiki Canasta rearranging some<br>> standard files for the Docker container which have been addressed.<br>> However, there are at least some Canasta Docker specific bugs relating to<br>> the Docker container environment. Please report any instances of "Error<br>> creating thumbnail: Unable to save thumbnail to destination" which I found<br>> in the Koha History page https://wiki.koha-community.org/wiki/History .<br>> Instances of the bug can be fixed with command line shell access by<br>> removing the images/thumb/$buggy_image_name subdirectory for the image and<br>> making non-changing edit to the page which allows MediaWiki to recreate<br>> the images/thumb subdirectory without a problem and the bug goes away. We<br>> should probably remove all the subdirectories in the images/thumb<br>> directory proactively. Yet, why is there a special problem for the Docker<br>> container which does not exist in other test instances when not using a<br>> Docker container and the container environment is running as the root user<br>> as standard for Docker containers and the root user should have all the<br>> permission necessary to access or create a thumbnail directory? Changing<br>> the ownership of the images directory and subdirectories back and forth to<br>> test the effect temporarily broke a test instance of the wiki until the<br>> container was restarted.<br>><br>> MAJOR ENHANCEMENTS FROM UPGRADING.<br>><br>> The VisualEditor extension used by Wikipedia is a WYSIWIG and guided forms<br>> aid for visually editing the underlying wikitext for a page and using<br>> guided forms for adding some features to a page. Users can switch back<br>> and forth between source editing in all wikitext syntax and VisualEditor,<br>> however, it may be best to save the current edit before switching back and<br>> forth to avoid problems of imperfect correspondence between wikitext<br>> syntax and the VisualEditor model of wikitext.<br>><br>> The AdvancedSearch extension used by Wikipedia is helpful for a user<br>> friendly interface to construct search queries and modify them by removing<br>> terms which appear in a bubble with an [x] to remove the term.<br>> AdvancedSearch depends on ElasticSearch which performs remarkably well in<br>> testing and allows the wiki to be reindexed in a couple of minutes if<br>> necessary. See further below for modifications to the AdvancedSearch<br>> extension.<br>><br>> SemanticMediaWiki was reinstalled after copying the upgraded database.<br>> Modifying the AdvancedSearch extension in conjunction with special<br>> AdvancedSearch navigation links and custom queries using carefully managed<br>> standard wiki categories may be more helpful than SemanticMediaWiki.<br>> Furthermore, anyone experimenting with SemanticMediaWiki should be aware<br>> that verbose syntax is required to avoid breaking most wikis with<br>> SemanticMediaWiki after forthcoming MediaWiki updates in which a hook<br>> commonly relied upon for SemanticMediaWiki which has been deprecated will<br>> be removed. Wikipedia does not use SemanticMediaWiki and thus some<br>> MediaWiki developers may not have given sufficient consideration to<br>> managing the issue. The workaround may involve a potential performance<br>> deficit when using SemanticMediaWiki search queries.<br>><br>> The MassEditRegex extension has power one might hope for in the name for<br>> using regular expressions to modify a list of pages. However, given its<br>> power it remains commented out in LocalSettings.php for the production<br>> system. Use is intended to be for some special group of users such as<br>> wiki administrors, however even they should be most strongly cautioned to<br>> first test their process on a test instance of the wiki. Furthermore, use<br>> should be with a bot subaccount set up by the user so that they may be<br>> identified as the work of a bot process and those mass changes may avoid<br>> adversely affecting page modification priorities in search result sets.<br>> The creation of user bot subaccounts should be documented. In testing,<br>> MassEditRegex works fantastically well for adding categories to the bottom<br>> of pages and templates to the top of pages which can be done without risk<br>> of an inadequately debugged regular expression breaking page content in<br>> the middle.<br>><br>> MODIFIED FEATURES.<br>><br>> I modified the following to support dynamic archiving in which obsolete<br>> content does not appear by default for search results unless the user goes<br>> directly to the advanced search page without following provided navigation<br>> links or changes the default VectorMod skin affecting the basic search<br>> box.<br>><br>> ADVANCEDSEARCH EXTENSION WITH MODIFICATIONS.<br>><br>> The AdvancedSearch extension has been modified to include two additional<br>> form elements: one for excluding particular categories and another for<br>> excluding particular templates. These additional elements appear in the<br>> user friendly AdvancedSearch term bubbles which can be individually<br>> removed from a query by clicking on the [x] for the particular bubble.<br>><br>> Editing the non-English localisation files is still pending. For<br>> languages for which a non-English localisation file has not been edited,<br>> the custom fields for category and template exclusion display a<br>> description in English.<br>><br>> DeepCategory searches for subcategories of a category is disabled because<br>> it requires a sparkle database and is only updated on a weekly basis for<br>> Wikipedia. Searching subcategories of a category should be less of an<br>> issue with faceted use of categories which we should be carefully moving<br>> towards.<br>><br>> Excluding particular categories supports dynamic archiving by supporting<br>> search queries excluding obsolete pages with -incategory:"Obsolete", which<br>> is automatically invoked from the navigation link "Advanced Search<br>> current" or from simple search box when using the modified Vector skin,<br>> VectorMod. Obsolete pages are also noted with a prominent notice using<br>> the Obsolete template. Such pages should be updated if they can be, but<br>> are otherwise available to consult most importantly for valuable<br>> information they often contain which is not yet present in current pages.<br>> Archived obsolete pages can be found exclusively by following the<br>> navigation link<br>> "Advanced search obsolete archive" which includes incategory:"Obsolete"<br>> automatically.<br>><br>> The result set for search queries with incategory:"Obsolete" can be used<br>> to identify the type of pages which should have the Obsolete category and<br>> Obsolete template but do not yet, such as installation information for<br>> some particular old Debian versions. Various combinations of including<br>> and excluding categories and templates can be easily used in the modified<br>> AdvancedSearch to find pages which only have one of either the Obsolete<br>> category or Obsolete template which should be used together or both<br>> removed if the page has been updated to be current.<br>><br>> All wiki pages should have some category even if it may be<br>> [[Category:Empty]] for people uncertain of what may be appropriate in the<br>> moment. Pages missing categories may not be disappearing from query<br>> results by category when using ElasticSearch indexing as they had been<br>> when using database based search indexing. We can also query for pages<br>> missing categories using<br>><br>> https://wiki.koha-community.org/w/index.php?title=Special:UncategorizedPages<br>> and correct the issue which has been neglected due to loss of time where<br>> migrating and upgrading the wiki has been the priority with much less time<br>> available otherwise especially since the pandemic.<br>><br>> We should take some care when thinking about faceted category use as no<br>> wiki software uses fielded categories. Thus there may be no concise way<br>> to query for pages which address a topic in a general way or supplement<br>> other documentation on a topic containing a lone category such as<br>> [[Category:Circulation]], if we then have many other pages with<br>> [[Category:RFCs]] and [[Category:Circulation]] but no longer<br>> [[Category:Circulation RFCs]] as a possible change for faceting. In such<br>> an example, the search results of a query for incategory:"Circulation"<br>> might have a result set in which pages for RFCs relating to circulation<br>> issues containing both [[Category:RFCs]] and [[Category:Circulation]]<br>> might crowd out more generally helpful pages with [[Category:Circulation]]<br>> alone. The problem may indicate a need for a navigation link to exclude<br>> RFCs from a search query; designating old RFCs as obsolete; or both.<br>> Alternatively or additionally, we may be able to adjust the weighting of<br>> the ElasticSearch indexing options such that pages containing<br>> [[Category:RFCs]] have a lower weight and appear further down the result<br>> set or pages with a single category such as [[Category:Circulation]] alone<br>> or some particular additional categories such as<br>> [[Category:Documentation]] have higher weight and appear further up the<br>> result set.<br>><br>> VECTORMOD SKIN.<br>><br>> Users are free to choose their own preferred MediaWiki skin and we can add<br>> others. VectorMod is merely set as the default to help people avoid<br>> obsolete pages when submitting search queries from the simple search box<br>> which appears on every page.<br>><br>> VectorMod is a custom version of the Vector skin which includes a modified<br>> version of Vector/includes/templates/SearchBox.mustache supporting dynamic<br>> archiving of obsolete content by excluding pages which have been<br>> designated obsolete by automatically adding -inCategory:"Obsolete" to<br>> basic search querries. The syntax incategory requires using<br>> ElasticSearch. Previously, I replaced the SearchBox.mustache file in the<br>> Vector skin<br>> directly, which certainly worked without the extra effort of creating a<br>> custom skin.<br>><br>> Automatically inserting -inCategory:"Obsolete" in the basic search box is<br>> now somewhat elegant in conjunction with the modified AvancedSearch<br>> extension as it uses explanatory language labels with a bubble which has a<br>> removal [x] and allows autocompletion of query terms.<br>><br>> Significant renaming of references to Vector as VectorMod and vector as<br>> vectormod has been scripted allows both Vector and VectorMod to be loaded<br>> and available to users.<br>><br>><br>> Thomas Dukleth<br>> Agogme<br>> 109 E 9th Street, 3D<br>> New York, NY 10003<br>> USA<br>> http://www.agogme.com<br>> +1 212-674-3783<br>><br>><br>> _______________________________________________<br>> Koha-devel mailing list<br>> Koha-devel@lists.koha-community.org<br>> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br>> website : https://www.koha-community.org/<br>> git : https://git.koha-community.org/<br>> bugs : https://bugs.koha-community.org/<br>><br><br><br>-- <br>Tomás Cohen Arazi<br>Theke Solutions (http://theke.io)<br>✆ +54 9351 3513384<br>GPG: B2F3C15F<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20221027/d381e112/attachment.htm><br><br>------------------------------<br><br>Subject: Digest Footer<br><br>_______________________________________________<br>Koha-devel mailing list<br>Koha-devel@lists.koha-community.org<br>https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br>website : https://www.koha-community.org/<br>git : https://git.koha-community.org/<br>bugs : https://bugs.koha-community.org/<br><br><br>------------------------------<br><br>End of Koha-devel Digest, Vol 203, Issue 16<br>*******************************************<br></div><br><br>NOTE: You are receiving this mail because, the Requester/Technician wanted you to get notified on this request creation.<br></body></html>