Extension talk:Page Exchange

This is the talk page for the Page Exchange extension.

Bug tracker edit

Is there any?
Alex Mashin (talk) 19:15, 1 August 2020 (UTC)Reply

Not yet, unfortunately - just this talk page. Yaron Koren (talk) 01:52, 2 August 2020 (UTC)Reply

This extension is a good idea edit

For some time I thought about the idea of "git for wikis", and now you have done it. It is a big achievement, and is likely to be useful, especially for wiki farms.

I have several ideas:

  • Is it necessary to define packages in LocalSettings.php? Why can't they be stored in the database, or, better, in the pages of a special namespace, perhaps, with its own data model?
  • A locally defined package can exist without its remote source. The pages that have to be downloaded and updated can either be listed locally; or their list can be extracted from a certain remote page, like a category, using text parsing tools similar to ones provided by External Data. The latter option requires extending package syntax to make it "dynamic".
  • Sources of data for a package don't even need to be wikis.
  • Another interesting topic is preprocessing foreign texts before their import. Thinking along these lines, I recently made a server-side wikifier tool (as a Lua module) that reproduces the behaviour of the current version of its JavaScript prototype.
  • "Pushing" packages to remote wikis could be interesting, although it will require authentication. Again, before pushing, texts can be preprocessed, and a package can define push requests other than using remote wiki's API.
  • If this extension develops according to these ideas, it can come to a point, when some of its code will become common with External Data. That may require librarisation.

Alex Mashin (talk) 03:54, 6 August 2020 (UTC)Reply

I'm glad you like the concept of this extension! And I hope you get to try it out yourself, if you haven't already. To be clear, packages are not defined in LocalSettings.php - they are only installed there. Packages are defined in JSON files that can be located anywhere on the web, and they don't need to be connected to a wiki at all.
What would be the benefit of preprocessing? Are you talking about translation?
"Pushing" is indeed interesting, especially for a wiki farm that might have hundreds of wikis whose data structures all need to be updated. Maybe the simplest approach to this is to create a Page Exchange API action that lets you update a package on a wiki from the command line - then you could have a script to update any combination of wikis at the same time. Yaron Koren (talk) 13:17, 7 August 2020 (UTC)Reply
  • To be clear, packages are not defined in LocalSettings.php — I think it is not necessary even to list packages in LocalSettings.php, if a package definition, be it a mere URL of a remote package or something more detailed like a list of pages, exists somewhere in the wiki database or on a dedicated page.
  • By preprocessing I mean, mainly, conversion of non-wiki texts into wiki markup or a reverse operation, when a page is "pushed" to a non-wiki site.

Alex Mashin (talk) 13:31, 7 August 2020 (UTC)Reply

Include Scribunto modules? edit

Hi Yaron

A quick question: I'm struggling to include Scribunto modules with PX. Am I right in assuming this format is correct (note the namespace and the url's file extension)?

{

"name": "MyModuleName",

"namespace": "NS_MODULE",

"url": "https://.../Module/MyModuleName.scribunto"

}

I noticed that using ".mediawiki" as a file extension will apply the wrong content model. So I tried ".scribunto".

However, it's not picked up by PX.

Am I missing something?

Many thanks for your support.

Lex LexSMW (talk) 14:05, 13 June 2022 (UTC)Reply

Hi - I'm guessing that you are using the "directoryStructure" setup, if a suffix other than ".mediawiki" is not getting picked up. But the suffix was not affecting the content model - rather, you found a bug in Page Exchange, where pages in the "Module" namespace were not being stored with the right content model. I just checked in what I think is a fix for this, here - if you get the latest Page Exchange code, and then uninstall and re-install the package, hopefully this will work correctly. Yaron Koren (talk) 02:08, 14 June 2022 (UTC)Reply
Hi, thanks for your prompt efforts!
I added PX' latest version as wfLoadExtension( 'PageExchange' ); (instead of cf...) to Canasta and I used the file extension .lua for the module pages.
Now I was able to import all pages with the single Install button and it seems to correctly import the module pages as Lua code.
However, when I now click Update / Uninstall I get a Fatal exception of type "Error". LexSMW (talk) 13:03, 14 June 2022 (UTC)Reply
Sorry about that - I clearly didn't fully test the change. (Though I'm glad installing works now.) I just checked in a fix, so again it should work if you get the latest code. Yaron Koren (talk) 14:06, 14 June 2022 (UTC)Reply
Yep, works now. Many thanks! LexSMW (talk) 14:37, 14 June 2022 (UTC)Reply

internal_api_error_ArgumentCountError when using api.php?action=pxupdatepackage edit

Hi

When https://localhost/w/api.php?action=pxupdatepackage&packageid=com.dataspects.EPPO.en I get:

{
  "error": {
    "code": "internal_api_error_ArgumentCountError",
    "info": "[237fdf4a58a5bfbb4406752c] Caught exception of type ArgumentCountError",
    "errorclass": "ArgumentCountError"
  }
}

That com.dataspects.EPPO.en exists as "globalID": "com.dataspects.EPPO.en" in page-exchange.json, but I get the same error even if that package ID wouldn't exist. I mention this because apparently if fails before reaching https://github.com/wikimedia/mediawiki-extensions-PageExchange/blob/295b032f913e1c3d80865dc7c9219e61834a0337/includes/api/PXUpdatePackageAPI.php#L32 LexSMW (talk) 08:52, 16 June 2022 (UTC)Reply

Sorry again. That's a bug that has been in the API for about a year now - you might be the first person to try using the API in that time! I just checked in what I think is a fix for it, here. Yaron Koren (talk) 17:47, 16 June 2022 (UTC)Reply
No problem! My pleasure to help you developing... ;)
So, your fix works. When run in an authenticated browser session I get back { }.
May I suggest to change that response into something like this?
{ "changed": [ "MediaWiki:Commons.css", "Form:Setup", "..." ] } LexSMW (talk) 07:17, 17 June 2022 (UTC)Reply

The extension works well, thank you! edit

Hi Yaron,

Congratulations and thank you for creating yet another great extension. Overall Page Exchange works super well on my install – syncing and updating packages all works exactly as expected. I'm about to launch a multi-site wiki and Page Exchange will make template management sooo much easier, so thank you very much for creating and sharing this :-)

Cheers,

Devaroo (talk)
18:33, 21 January 2024 (UTC)Reply

Solved Bug report: Extension breaks MediaWiki:Group-user.css edit

Product Version
MediaWiki 1.39.5
Page Exchange 0.6.1
PHP 8.0.30
MariaDB 10.5.23-MariaDB
ICU 66.1
Lua 5.1.5
Pygments 2.11.2

Hi Yaron,

When this extension is enabled, the special page MediaWiki:Group-user.css doesn't load CSS just for logged-in users (expected behavior) but for all users (incl. anonymous). Disabling the Page Exchange extension resolves this issue, re-enabling it brings the issue back.

Btw, MediaWiki:Group-user.css was amongst my synced pages but removing it from the list doesn't resolve the issue.

Cheers,

Devaroo (talk)
18:37, 21 January 2024 (UTC)Reply

I'm glad you are enjoying Page Exchange! Yes, that was a bug - I had forgotten about the whole "Group-" thing. I just checked in what I think is a fix for it, here - if you can, please try it out and let me know if it works for you. Yaron Koren (talk) 16:24, 22 January 2024 (UTC)Reply
Hi Yaron, I can confirm the fix prevents the reported issue on my site. Thank you 🙂 🙏 Devaroo (talk) 01:02, 23 January 2024 (UTC)Reply
Great to hear. Yaron Koren (talk) 15:15, 23 January 2024 (UTC)Reply
Return to "Page Exchange" page.