Extension talk:VisualData

Uncaught TypeError: mw.widgets.TitleInputWidget is not a constructor

Hi,

I really like the approach of the extension - thanks for that!

When trying to add a new field to schema definition, I get the following error: Uncaught TypeError: mw.widgets.TitleInputWidget is not a constructor.

The widget popup does not appear. Other widgets like Add content block, add subtiem and Add geolocation work.

Tested with a fresh installation of MW1.39 and MW1.41 and latest master branch of the extension.

Thanks for support! Filburt (talk) 09:34, 22 February 2024 (UTC)

Ok, I may have found the error: In the file /resources/VisualDataFormField.js in line 204 it must be instead of:

var wikilistInput = new mw.widgets.TitleInputWidget( { 

as follows:

var wikilistInput = new OO.ui.TextInputWidget( { 

Hope, it helps... Filburt (talk) 11:12, 22 February 2024 (UTC)

hello @Filburt I'm not sure I can reproduce, here https://wikisphere.org/wiki/Main_Page there is a similar installation and the mw.widgets.TitleInputWidget works as well Thomas-topway-it (talk) 18:54, 22 February 2024 (UTC)

can you try to add "mediawiki.widgets" to the dependencies of ext.VisualData.Common or ext.VisualData.ManageSchemas ? (extension.json) -- It's possible on my install is loaded in some other way but should indeed be required Thomas-topway-it (talk) 20:25, 22 February 2024 (UTC)

Thanks for the quick reply! Adding the mediawiki.widgets as a dependency of ext.VisualData.Common works.

I had also thought in the direction that it is somehow loaded differently. Filburt (talk) 08:25, 23 February 2024 (UTC)

API Error when trying to delete a schema

Hi,

I have another question: When clicking - Manage Schema > XYZ > Delete - I get the following API call error:

visualdata-save-schema internal_api_error_Error VisualDataSchemas.js:699:17

   callApi VisualDataSchemas.js:699

   jQuery 31

   xhr index.js:292

   jQuery 6

   ajax index.js:270

   post index.js:154

   postWithToken index.js:352

Any idea? Thanks for support! Filburt (talk) 15:45, 23 February 2024 (UTC)

can you please post the server side debug ? (using $wgDebugLogFile and then retrieving the related error ) thank you Thomas-topway-it (talk) 20:43, 23 February 2024 (UTC)

no need to post it, I can reproduce, I will back shortly Thomas-topway-it (talk) 20:47, 23 February 2024 (UTC)

just updated to the last version Extension:VisualData/Release notes Thomas-topway-it (talk) 11:29, 24 February 2024 (UTC)

Thanks a lot for the great support - it works correctly! Filburt (talk) 15:20, 24 February 2024 (UTC)

Features

Hi again,

I'm diving deeper into VisualData and have two questions:

1. is it possible to generate the page title from another field and

2. can individual fields be prefilled via the form call?

Thanks a lot! Filburt (talk) 17:50, 12 March 2024 (UTC)

hello Filburt:

1) you can use a pagename formula Extension:VisualData/Forms

2) you can use preload-data Extension:VisualData/Forms or the default value for specific fields Thomas-topway-it (talk) 09:44, 13 March 2024 (UTC)

Thanks for the quick reply!

1. This works this way: pagename-formula = <fieldname> - great!

2. What would be the syntax to fill a single field with preload-data? (I was only able to load a complete JSON-dataset)

Thank you! Filburt (talk) 10:43, 13 March 2024 (UTC)

@Filburt with preload data I think you cannot fill a single field, unless you don't leave the other fields as null values but I should test. I was also thinking to add an option to update the article title if it depends by a field on subsequent edits of the form, since for now it only works on creation. In case let me know if you have a use-case for that Thomas-topway-it (talk) 08:42, 16 March 2024 (UTC)

for the single field the default value does not work ? Thomas-topway-it (talk) 08:44, 16 March 2024 (UTC)

Hello Thomas,

My use case is a tree structure where I need the option to add a new child element in each level. To do this, I need to tell the child elements what their parent element is. The tree structure is displayed using nested templates, something like this:

Level x
|- Level x.x
|  |  |- Level x.x.x
|  |  + Add item x.x.x
|- Level x.x
|  |  |- Level x.x.x
|  |  |- Level x.x.x
|  |  + Add item x.x.x
|  + Add item x.x
|- Level x.x
|  |  + Add item x.x.x
|  + Add item x.x
+ Add item x

Ideally, I could add something like 'belongs_to' and then a template parameter like {{{parent-level-field}}}, i.e. the value of a field from VisualData that is queried in the higher-level template.

I have already considered how it could be best implemented syntactically, perhaps by extending the preload parameter - similar to the template parameter in the queries:

|preload?visualdatafieldname = xyz or |preload <visualdatafieldname> = xyz

in my case:

|preload?belongs to = {{{parent-level-field}}} or |preload <belongs to> = {{{parent-level-field}}}

Many thanks & best regards Filburt (talk) 11:02, 16 March 2024 (UTC)

interesting. Do you have an online demo or can you try to reproduce a partially working version on https://wikisphere.org/wiki/Main_Page to evaluate it better ? Thomas-topway-it (talk) 09:37, 17 March 2024 (UTC)

Hi Thomas,

I have added a more general example here:

https://wikisphere.org/wiki/User:Filburt/Nested_Schemas_and_Templates_Example

In this example there are the three different levels School district, School and School class. In the output there is a button below each level to add new items.

In order for these elements to be automatically assigned to the right place in the tree, I would have to give them the parent item, which would have to be preselected in the 'Belongs to' field. Therefore, it would be useful if the template paramter {{{name}}} could be added as parameter to the form button.

Unfortunately, it does not work if I set {{{name}}} as the default value directly in the form, as the context of the template is missing.

(Probably the cache has to be cleared to see new items)

I hope the example is understandable.

Many thanks! Filburt (talk) 13:17, 18 March 2024 (UTC)

interesting. Thank you for the demo. I think it is unrelated to this, however for your information yesterday I've added another feature Extension:VisualData/QueryLink parser function -- I will document it better.

Regarding your demo, yes, if the data has to be retrieved from the template the preload-data with a syntax as suggested by you seems the only way. I will send an update about this as soon as possible Thomas-topway-it (talk) 17:02, 18 March 2024 (UTC)

also, this is interesting because it combines different schemas, however, this can be also managed by a unique schema with subitems, (subitems can be also arrays, so the tree can be implemented) have you also tried this path ? Thomas-topway-it (talk) 17:22, 18 March 2024 (UTC)

Yes, I was thinking in that direction, but it would make the form very long and complex, maybe the partial editing of schemas mentioned in your roadmap will be a solution in the future... Filburt (talk) 17:37, 18 March 2024 (UTC)

done https://wikisphere.org/wiki/User:Filburt/Nested_Schemas_and_Templates_Example

already published as last version Thomas-topway-it (talk) 09:11, 19 March 2024 (UTC)

it requires to run composer install in the extension folder Thomas-topway-it (talk) 09:13, 19 March 2024 (UTC)

Hi Thomas,

Thanks a lot - it works!

At the moment I try to figure out the following:

I prefill preload-data?belongs_to = {{{articleid}}}. In the related form I don't want to show the articleid but the related title. I tried to use the DropdownInputWidget and to build a query for the Options label formula as follows (but it doesn't work):

{{#visualdataquery: [[belongs_to::<value>]] |?title |schema=Test |format=raw }}

Any idea?

Thank you! Filburt (talk) 17:40, 20 March 2024 (UTC)

first can you check if "belongs_to" with underscore is correct ? (in your example there is just space). <value> in any case should be filled with the value from the input, so if the value from the input is retrieved from the template, it should work. Could I also post somewhere else your use-case (i.e. the page you have created on wikisphere) to which other users may be interested ? thank you Thomas-topway-it (talk) 07:01, 21 March 2024 (UTC)

and also "belongs to" currently takes the title, not the article id Thomas-topway-it (talk) 07:08, 21 March 2024 (UTC)

Hi Thomas,

I have updated my example on Wikisphere (https://wikisphere.org/wiki/User:Filburt/Nested_Schemas_and_Templates_Example). The 'belongs to' field now works with IDs. Now I'm trying to display the name of the parent element as a label in a DropdownInputWidget in the form instead of the ID - see schemas for School and School class.

Another problem I encountered: I also use URL parameters, which I read out with {{#urlget:...}}. However, return-page does not work with URL parameters at the moment.

Thanks a lot! Filburt (talk) 16:00, 21 March 2024 (UTC)

hello, I have added the support for the query in return-page. https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/VisualData/+archive/14f6d9bda6e3cdc9ed14ed560d58bf36f7623502.tar.gz -- I'm not sure why you want to have the dropdown pageid => page title, shouldn't remain hidden ? However the following query does not work:

{{#visualdataquery:[[articleid::<value>]]|?name|schema=School district|format=raw}}

but the following should work

{{#visualdataprint:<value>|?name|schema=School district|format=raw}} Thomas-topway-it (talk) 06:41, 22 March 2024 (UTC)

Hi, the idea behind is to have the possibility to clone items and attach them to other parents.

Unfortunately, the query is still not working for me. The articleid does not seem to appear as <value> in the DropdownInputWidget. Thank you! Filburt (talk) 14:18, 22 March 2024 (UTC)

can you try now ? https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/VisualData/+archive/5391fc64fe4376b2f1d68ef288d224395d49f6e7.tar.gz

added <articleid> in all query results and updated dialog messages at this regards, now are more clear. There was also a typo that prevented options-label-formula to work Thomas-topway-it (talk) 22:45, 22 March 2024 (UTC)

Hi, thanks for the changes! I think we almost have it. However, at the moment I get the error message 'must be equal to one of the allowed values' when I try to save a new item (i.e. add a new school). I already tried to add the <articleid> as default value, but that didn't work. Thanks! Filburt (talk) 14:14, 25 March 2024 (UTC)

@Filburt I've done https://www.mediawiki.org/wiki/Special:ExtensionDistributor?extdistname=VisualData&extdistversion=master -- however can you check that it works correctly ? thank you Thomas-topway-it (talk) 09:16, 30 March 2024 (UTC)

regarding <articleid> it does not work as default value, only in input options Thomas-topway-it (talk) 09:21, 30 March 2024 (UTC)

Super - now it works correctly - Thanks a lot! Filburt (talk) 19:50, 3 April 2024 (UTC)

General thoughts on the preload parameter

Hi Thomas, I have been thinking about the following: Currently, when using the preload parameter in the form definition, the complete wikitext of the specified page is rendered into the page that is generated by VisualData. Wouldn't it make more sense to specify a template at this point? In other words, the free text of the generated page would only contain {{My template}} and this template could then contain a visualprint statement, for example. In this way, all pages generated with a specific form could be modified at once (e.g. for layout reasons).

To do this, the raw string specified in the preload parameter, e.g. |preload = {{My template}}, would simply have to be inserted into the new page (without searching for a corresponding page title or being rendered).

What do you think? Thank you!

Filburt (talk) 16:13, 4 April 2024 (UTC)

hi @Filburt first -- are you able to setup a working version of your workflow here https://wikisphere.org/wiki/User:Filburt/Nested_Schemas_and_Templates_Example as you did at the beginning ? This could be used for reference also for others in case they want to manage multiple dependent schemas.

Regarding the last comment, I'm not sure to understand the benefit of your proposal, if you preload a standard wikitext article, aren't you already able to include queries and templates as well ? (that page could contain only the string {{My template}} in your case) Thomas-topway-it (talk) 18:51, 8 April 2024 (UTC)

Hi @Thomas-topway-it I just wanted to update my example - unfortunatelly my query

{{#visualdataquery:[[belongs to::{{{articleid}}}]]|...}}

no longer seems to work, see: https://wikisphere.org/w/index.php?title=Template:School_district&veaction=editsource

The correct ID is stored on the corresponding pages under 'belongs to', see e.g. https://wikisphere.org/wiki/School/46

Is {{{articleid}}} (received from parent page/template) rendered in der query? Has it changed in the latest VisualData version?

Thanks a lot! Filburt (talk) 12:22, 10 April 2024 (UTC)

hello Fliburt, I've setup this https://wikisphere.org/wiki/User:Filburt/Nested_Schemas_and_Templates_Example

for me it works, but let me know if some data is missing Thomas-topway-it (talk) 20:05, 10 April 2024 (UTC)

Hi @Thomas-topway-it, Yes, the example works now, no idea what the problem was. Btw. I find VisualData really great (I worked with PageForms for a long time - that was also the reason why I suggested the direct input of a template for the preload parameter). At the moment I'm still experimenting a lot with VisualData... Filburt (talk) 20:10, 11 April 2024 (UTC)

Small bug in VisualDataForms.js

Hi, I found a small bug in VisualDataForms.js line 1740 - it should be:

ThisPageLayout.super.call( this, name, thisConfig );

Otherwise the booklet layout will not work.

Greetings Filburt (talk) 21:03, 11 April 2024 (UTC)

MediaWiki version compatibility

Hi!

First of all: this is a very interesting extension! Thanks for creating it.

I tried to install it, but unfortunately ran into some issues:

1. When installed on MediaWiki 1.39, in many cases the JavaScript is not properly loaded: E.g. when accessing action=editdata the JavaScript console shows an error Uncaught SyntaxError: await is only valid in async functions and the top level bodies of modules

2. When installed on MediaWiki 1.42, I get a database error when trying to "browse" the data (accessing SpecialVisualDataBrowse)

[3015f5a54dcf1202071f4f64] /w/index.php?title=Spezial:VisualDataBrowse/Data Wikimedia\Rdbms\DBLanguageError: Table name component contains unexpected quote or dot character

Backtrace:

from /var/www/htdocs/w/includes/libs/rdbms/platform/SQLPlatform.php(1051)
#0 /var/www/htdocs/w/includes/libs/rdbms/platform/SQLPlatform.php(991): Wikimedia\Rdbms\Platform\SQLPlatform->extractTableNameComponents(string)
#1 /var/www/htdocs/w/includes/libs/rdbms/platform/SQLPlatform.php(957): Wikimedia\Rdbms\Platform\SQLPlatform->qualifiedTableComponents(string)
#2 /var/www/htdocs/w/includes/libs/rdbms/platform/SQLPlatform.php(936): Wikimedia\Rdbms\Platform\SQLPlatform->tableName(string)
#3 /var/www/htdocs/w/includes/libs/rdbms/platform/SQLPlatform.php(837): Wikimedia\Rdbms\Platform\SQLPlatform->tableNameWithAlias(string, string)
#4 /var/www/htdocs/w/includes/libs/rdbms/platform/SQLPlatform.php(666): Wikimedia\Rdbms\Platform\SQLPlatform->tableNamesWithIndexClauseOrJOIN(array, array, array, array)
#5 /var/www/htdocs/w/includes/libs/rdbms/database/Database.php(3334): Wikimedia\Rdbms\Platform\SQLPlatform->selectSQLText(array, array, array, string, array, array)
#6 /var/www/htdocs/w/includes/libs/rdbms/database/DatabaseMySQL.php(730): Wikimedia\Rdbms\Database->selectSQLText(array, array, array, string, array, array)
#7 /var/www/htdocs/w/includes/libs/rdbms/database/Database.php(1342): Wikimedia\Rdbms\DatabaseMySQL->selectSQLText(array, array, array, string, array, array)
#8 /var/www/htdocs/w/includes/libs/rdbms/database/DBConnRef.php(119): Wikimedia\Rdbms\Database->select(array, array, array, string, array, array)
#9 /var/www/htdocs/w/includes/libs/rdbms/database/DBConnRef.php(351): Wikimedia\Rdbms\DBConnRef->__call(string, array)
#10 /var/www/htdocs/w/includes/pager/IndexPager.php(467): Wikimedia\Rdbms\DBConnRef->select(array, array, array, string, array, array)
#11 /var/www/htdocs/w/includes/pager/IndexPager.php(289): MediaWiki\Pager\IndexPager->reallyDoQuery(string, integer, boolean)
#12 /var/www/htdocs/w/includes/pager/IndexPager.php(739): MediaWiki\Pager\IndexPager->doQuery()
#13 /var/www/htdocs/w/extensions/VisualData/includes/specials/SpecialVisualDataBrowse.php(149): MediaWiki\Pager\IndexPager->getNumRows()
#14 /var/www/htdocs/w/includes/specialpage/SpecialPage.php(718): SpecialVisualDataBrowse->execute(string)
#15 /var/www/htdocs/w/includes/specialpage/SpecialPageFactory.php(1669): MediaWiki\SpecialPage\SpecialPage->run(string)
#16 /var/www/htdocs/w/includes/actions/ActionEntryPoint.php(504): MediaWiki\SpecialPage\SpecialPageFactory->executePath(string, MediaWiki\Context\RequestContext)
#17 /var/www/htdocs/w/includes/actions/ActionEntryPoint.php(145): MediaWiki\Actions\ActionEntryPoint->performRequest()
#18 /var/www/htdocs/w/includes/MediaWikiEntryPoint.php(199): MediaWiki\Actions\ActionEntryPoint->execute()
#19 /var/www/htdocs/w/index.php(58): MediaWiki\MediaWikiEntryPoint->run()
#20 {main}

I tested different versions of the extension (REL1_42 and current master) and of MediaWiki (1.39 and 1.42). Besides some standard extensions like VisualEditor and WikiEditor, I do not have any other extension enabled. The browser was Google Chrome 124. Osnard (talk) 05:56, 26 April 2024 (UTC)

I can confirm it works with MW1.41 (1.42 is not yet fully supported). Don't forget to run

composer install --no-dev

in the VisualData extension folder.

Hope it helps. Filburt (talk) 07:50, 26 April 2024 (UTC)

hello Robert @Osnard, they are known issues. Regarding the first please use $wgResourceLoaderDebug = true; in LocalSettings.php -- this is caused in certain cases by the ResourceLoader and I'm not sure if there is a fix for that. Regarding 1.42 as mentioned by Filburt, it's not yet fully supported (or tested). Thomas-topway-it (talk) 08:21, 26 April 2024 (UTC)

I can confirm, $wgResourceLoaderDebug = true; solved the await issue on MediaWiki 1.39. Osnard (talk) 13:48, 26 April 2024 (UTC)

Small enhancements

Hi Thomas, I have made some minor changes and enhancements to VisualData, which - if desired - can also be incorporated into the official VisualData branch. To demonstrate the functions, I have set up a wiki, see https://visualdata.idea-sketch.com

I have done the following things:

• extended the form paramter preload-data for use with multiple and nested values more (that still needs to be improved in detail)
• Introduction of a form parameter selected-schema to preselect a tab when multiple form schemas are attached more
• Result Format count more
• Result format json-raw activated more

Let me know if there is interest in these things (currently they are still for VisualData v1.0.6 ). What would be the best way to send the code, via pull request?

I have noticed a few more feature ideas and bugs that I have collected here

I have also programmed a small extension that numbers the page titles similar to the <unique number> parameter in PageForms, see here: Extension:UniquePageTitle (as alternative to the extension IDProvider)

Greetings, Filburt (talk) 11:35, 16 May 2024 (UTC)

hello @Filburt thanks a lot for your contributions. I have just uploaded a commit that should fix all the issues mentioned here https://visualdata.idea-sketch.com/wiki/Main_Page (some of them were already fixed) except possibly "VE (VEForAll) does not load in inactive form tabs". Regarding the ideas here https://visualdata.idea-sketch.com/wiki/Main_Page I think in general could you create a patch on gerrit ? It is better if you create first a patch for those most simple, excluding for now "Preload data with nested and multiple values". By the way, aren't nested preload data already supported ? Thomas-topway-it (talk) 09:01, 17 May 2024 (UTC)

Ok, I'll have to take a closer look at Gerrit first and will then make the patches available.

I have updated the bug list on http://visualdata.idea-sketch.com

In v1.0.8 I noticed that the internationalization of labels no longer works, e.g. {{int:User}}.

Regarding the multiple and nested preload-data: My idea is to generate the values for the preload-data dynamically from VisualData queries, see the second code example here

Is there another way to do this?

Filburt (talk) 10:13, 21 May 2024 (UTC)

Ok, I noticed that the internationalization of the labels works again when the schemas are saved again. In the future, it would be great if internationalization would also work for default values for radio buttons or checkboxes that are defined in the FormBuilder or come from templates... Filburt (talk) 19:51, 21 May 2024 (UTC)

Error: Call to a member function error() on null

After running the script extensions/VisualData/maintenance/RebuildData.php I get the error. Also editing with VisualEditor is not possible. Testet with master branch an MW 1.38.8 and 1.42.1. [f0a1a16d624f53e473dd5c5d] [no req] Error: Call to a member function error() on null Backtrace: from /var/www/html/extensions/VisualData/includes/classes/SchemaProcessor.php(250)

1. 0 /var/www/html/extensions/VisualData/includes/classes/SchemaProcessor.php(165): MediaWiki\Extension\VisualData\SchemaProcessor->getAllowedMimeTypes()
2. 1 /var/www/html/extensions/VisualData/includes/VisualData.php(1341): MediaWiki\Extension\VisualData\SchemaProcessor->__construct()
3. 2 /var/www/html/extensions/VisualData/includes/VisualData.php(1328): VisualData::getSchemas()
4. 3 /var/www/html/extensions/VisualData/includes/VisualData.php(1134): VisualData::getSchema()
5. 4 /var/www/html/extensions/VisualData/includes/VisualData.php(1037): VisualData::getResults()
6. 5 /var/www/html/extensions/VisualData/includes/VisualData.php(905): VisualData::parserFunctionQuery()
7. 6 /var/www/html/includes/parser/Parser.php(3445): VisualData::parserFunctionPrint()
8. 7 /var/www/html/includes/parser/Parser.php(3130): MediaWiki\Parser\Parser->callParserFunction()
9. 8 /var/www/html/includes/parser/PPFrame_Hash.php(275): MediaWiki\Parser\Parser->braceSubstitution()
10. 9 /var/www/html/includes/parser/Parser.php(2964): PPFrame_Hash->expand()
11. 10 /var/www/html/includes/parser/Parser.php(1614): MediaWiki\Parser\Parser->replaceVariables()
12. 11 /var/www/html/includes/parser/Parser.php(722): MediaWiki\Parser\Parser->internalParse()
13. 12 /var/www/html/includes/content/WikitextContentHandler.php(376): MediaWiki\Parser\Parser->parse()
14. 13 /var/www/html/includes/content/ContentHandler.php(1664): WikitextContentHandler->fillParserOutput()
15. 14 /var/www/html/includes/content/Renderer/ContentRenderer.php(67): ContentHandler->getParserOutput()
16. 15 /var/www/html/includes/Revision/RenderedRevision.php(260): MediaWiki\Content\Renderer\ContentRenderer->getParserOutput()
17. 16 /var/www/html/includes/Revision/RenderedRevision.php(232): MediaWiki\Revision\RenderedRevision->getSlotParserOutputUncached()
18. 17 /var/www/html/includes/Revision/RevisionRenderer.php(226): MediaWiki\Revision\RenderedRevision->getSlotParserOutput()
19. 18 /var/www/html/includes/Revision/RevisionRenderer.php(164): MediaWiki\Revision\RevisionRenderer->combineSlotOutput()
20. 19 [internal function]: MediaWiki\Revision\RevisionRenderer->MediaWiki\Revision\{closure}()
21. 20 /var/www/html/includes/Revision/RenderedRevision.php(199): call_user_func()
22. 21 /var/www/html/includes/page/ParserOutputAccess.php(379): MediaWiki\Revision\RenderedRevision->getRevisionParserOutput()
23. 22 /var/www/html/includes/page/ParserOutputAccess.php(330): MediaWiki\Page\ParserOutputAccess->renderRevision()
24. 23 /var/www/html/includes/page/WikiPage.php(1229): MediaWiki\Page\ParserOutputAccess->getParserOutput()
25. 24 /var/www/html/extensions/VisualData/maintenance/RebuildData.php(154): WikiPage->getParserOutput()
26. 25 /var/www/html/extensions/VisualData/maintenance/RebuildData.php(105): RebuildData->rebuildLinks()
27. 26 /var/www/html/maintenance/includes/MaintenanceRunner.php(698): RebuildData->execute()
28. 27 /var/www/html/maintenance/doMaintenance.php(100): MediaWiki\Maintenance\MaintenanceRunner->run()
29. 28 /var/www/html/extensions/VisualData/maintenance/RebuildData.php(313): require_once

194.29.99.250 13:25, 16 July 2024 (UTC)

Seem's it is a problem with the Logger:

/var/www/html/extensions/VisualData/includes/classes/SchemaProcessor.php

\VisualData::$Logger->error(... 194.29.99.250 11:09, 17 July 2024 (UTC)

I remember I did fix the issue with the logger in a recent patch, could you please ensure you are using the latest commit ? Also, as mentioned below, please note that 1.42 is not yet fully supported, namely the importer does not work. Thomas-topway-it (talk) 08:09, 19 July 2024 (UTC)

Extension Compatibility and Switching from SMW to VisualData

My wiki currently uses semantic mediawiki, but we're concerned about its support long-term, so we're considering switching to VisualData. However, our wiki uses SMW in so many places that it would be easiest to have a transition period where we add the VisualData extension, implement it into templates and modules that store data, and then switch our various SMW-dependent systems over one by one, like we did when we converted all our DPL-dependent systems to use SMW instead.

However, I'm currently having flashbacks to when we switched from Cargo to SMW, which are not compatible; we were basically left with no choice but to remove Cargo and scramble to fix every single template that used it as fast as possible, which was kinda awful for user experience.

Basically, I want to be fully prepared--will switching over be more like the former or the latter? Disgustedorite (talk) 19:28, 17 July 2024 (UTC)

Well, Miraheze answered that for us by upgrading to the latest version of MediaWiki, which seems to have completely broken SMW. If VisualData is still compatible / can be updated faster than SMW (very likely), it's gonna be like the latter. sigh Disgustedorite (talk) 23:12, 17 July 2024 (UTC)

@Disgustedorite that's a good point. Basically the two extensions (SMW and VisualData) should be able to coexist without interfering each other. That means that you can keep your SMW install and then incrementally cloning your data to be managed by VisualData. At the same time, VisualData has to be enhanced with additional result printers not yet available, but that I might be interested to implement. Also, please take into account that VisualData currently supports MW between 1.35 - 1.41 -- with 1.42 the importer does not work yet, despite it won't take much time to fix.

The issue with SMW is that its inherently complexity (size of source code) makes it difficult to maintain when it entails the redesign of its core functions, which encompass a large number of files, and tests, which are quite difficult (even impossible, unless there isn't a specific business project aimed to that) to go through and analyze. Of course if (apart being a mere user) some of you want to onboard into VisualData development you are welcome. Thomas-topway-it (talk) 08:00, 19 July 2024 (UTC)

Thank you for your response. Unfortunately, however, I've decided against using it over concerns about how the data is stored and displayed, which is unintuitive, incompatible with our current setup, and tedious for our editors to work with (avoiding all of the above is exactly why we were using SMW instead of Cargo), and whether data is actually stable and unlikely to be lost from an incompatible update or our farm suddenly deciding to disable the extension when it's stored the way it is. We will be making an extension-independent solution of our own which won't be potentially vulnerable to being broken by a wiki farm speedrunning mediawiki updates, unless they completely change the API for some reason. Apologies for wasting your time. Disgustedorite (talk) 15:54, 19 July 2024 (UTC)

hello @Disgustedorite I don't want to push you in any way to use this extension. While I'm not sure to fully understand the passage "We will be making an extension-independent solution of our own which won't be potentially vulnerable to being broken by a wiki farm speedrunning mediawiki updates", if you keep using SMW that's great, since it is a great software and still actively maintained. That said, one of the strengths of VisualData is precisely how data are stored, since it uses slots (see Multi-Content Revisions) which offers the following advantages:

• the data are stored in standard MW tables and do not depend on the extension
• the data are subjected to Revision's history and therefore all the changes are recorded
• there is a separation between content of the article and their metadata (this is also the solution chosen by Open CSP whose company (Wikibase solution) inspired me for the use of slots)
• the data are stored in json-format (json-schema compliant) -- while there is no need I present the first (this allows, by the way, the use of structured, hierarchical data) the latter is the industry standard for data validation and interoperability
• MediaWiki will increasingly provide more support for easy (built-in) editing of slots, and as far as I know the source code is moving in that direction

This of course does not prevent that you can implement or chose completely different solutions which of course have their strengths. I just would like to point out that there is no way you lose your data also if you remove the extension or by running "speedrunning mediawiki updates" within the context of a WikiFarm. If you uninstall the extension you have only to be sure that the content model (currently named "jsondata") is registered on the wiki for which actually I could provide a separate tool to ensure that. (or even to evaluate to downgrade to simply using the json-format, if the conditions exist)

all the best

(Thomas) Thomas-topway-it (talk) 08:03, 20 July 2024 (UTC)