Move prepare_extensions_skins_symlinks() up in run-apache.sh

[pastakhov]

We should prepare the symlinks at the firts step (at least before we call get_mediawiki_variable() function, in other case get_mediawiki_variable does not work (throws errors) because extensions and skins don't exist (the symlynks were not created)

P.S. I don't like this idea with symlynks very much.

[yaronkoren]

@pastakhov - could you keep the function where it was before, so that it's easier to see what the changes are? Unless there is a reason to move it.

Also, since we're already talking about it: what do you think should be done instead of symlinks?

[pastakhov]

I didn't change the function, I moved it up because we should declare functions before calling them and we should call the function at the first step. And this is major issue, should be checked, tested, merged asap.

[github-actions[bot]]

Image is built and pushed to the repository as ghcr.io/canastawiki/canasta:1.35.8-20221125-158

[pastakhov]

what do you think should be done instead of symlinks?

I told it several times, a small patch for mw core to check skins extensions in both directories, and modified apache settings to do the same should work much better. if changes in mw core are not acceptable, we should use a watcher (inotifywait) and create/remove symlynks when user adds/removes extensions/skins in the folders.

[yaronkoren]

Okay, I get it. Could you change the patch title to make this clearer? Maybe just changing "Fix" to "Move" would explain it better.

That's very interesting, about possibly patching MW core - I don't remember that previous discussion. Was it on GitHub? If so, it would be good to continue it. Nothing is "set in stone" regarding the loading of extensions and skins.

[yaronkoren]

Also, I agree that, if we stick with symlinks, a "watcher" using inotifywait would be great to have - and it would eliminate the need for special error reporting if things go wrong, which I suggested in #146.

[jeffw16]

Using inotifywait sounds good as long as we are careful about not causing race conditions later on in development if we decide to do more stuff with handling extensions and skins.

[vedmaka]

Runtime symlinks management based on inotifywait definitely makes sense for me, so +1. However, it does look like it imposes some new challenges:

1. User puts extension directory into user-extensions mount first, then goes to settings file and adds wfLoadExtension call). In this case running update script right after new directory was detected/symlink created will do nothing and thus we should (somehow) wait for wfLoad presence (add automatically? hm..)

2. User adds wfLoad first and then puts extensions files into user-extensions mount. In this case running update triggered by inotifywait will make sense (though I assume it'll require some delay to ensure extension files copying was fully completed)

[yaronkoren]

@vedmaka - I think the rest of us were just talking about using inotifywait to create symlinks, not to run update.php. Trying to run update.php automatically, though it could be convenient, is probably too complex to try to do, as you note; and it might end up confusing the administrator.

[pastakhov]

And I didn't test this patch... just in case...

[github-actions[bot]]

Image is built and pushed to the repository as ghcr.io/canastawiki/canasta:latest,ghcr.io/canastawiki/canasta:1.2.1,ghcr.io/canastawiki/canasta:1.35-latest,ghcr.io/canastawiki/canasta:1.35.8-latest,ghcr.io/canastawiki/canasta:1.35.8-20221126-89d3927