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)
- Not yet, unfortunately - just this talk page. Yaron Koren (talk) 01:52, 2 August 2020 (UTC)
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)
- 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)
- 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.
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)
- 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)
- 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 aFatal exception of type "Error"
. LexSMW (talk) 13:03, 14 June 2022 (UTC)- 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)
- Yep, works now. Many thanks! LexSMW (talk) 14:37, 14 June 2022 (UTC)
- 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)
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)
- 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)
- 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)
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,
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)
- 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)
- Hi Yaron, I can confirm the fix prevents the reported issue on my site. Thank you 🙂 🙏 Devaroo (talk) 01:02, 23 January 2024 (UTC)
- Great to hear. Yaron Koren (talk) 15:15, 23 January 2024 (UTC)
- Hi Yaron, I can confirm the fix prevents the reported issue on my site. Thank you 🙂 🙏 Devaroo (talk) 01:02, 23 January 2024 (UTC)