Jump to content

Extension talk:Page Exchange

Add topic
From mediawiki.org

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