From: egel <eg...@sc...> - 2014-01-14 20:59:59
|
Semantic MediaWiki (Versie 1.8.0.5) and MW 1.22.1 breaks uploads of images and saving of edits We also use Maps and we don't want use unstable or development versions. -- Met Vriendelijke Zwerversgroeten Wouter Rademaker |
From: egel <eg...@sc...> - 2014-01-15 15:24:55
|
James HK schreef op 2014-01-14 22:43: > Hi, > >> We also use Maps and we don't want use unstable or development >> versions. > > SMW 1.9 has been officially released [1] but developers and users are > always free and encouraged to submit patches for past and future > releases. > > PS: It might be that some core developers share some of their time (as > for myself, I don't have time to support legacy releases) to create > patches for outdated releases (1.8 has been superseded as 1.9 is > released). > > [1] > http://wikimedia.7.x6.nabble.com/Semantic-MediaWiki-1-9-released-td5019491.html > > Cheers > So far as I can find, forces upgrading to SMW 1.9 you to upgrade (Semantic) maps to a unstable / development version. Or is there a way to use SMW 1.9 and (Semantic) maps 2.0 at the same time? Installation of SMW 1.9 needs Composer and because only 2 wiki's on our wikifarm, http://www.scoutwiki.org , are using Semantic extensions, will Composer only add more complexities. Or can you still use git to update SMW? > On 1/15/14, egel <eg...@sc...> wrote: >> Semantic MediaWiki (Versie 1.8.0.5) and MW 1.22.1 breaks uploads of >> images and saving of edits -- Met Vriendelijke Zwerversgroeten Wouter Rademaker |
From: [[kgh]] <med...@kg...> - 2014-01-15 15:41:03
|
Heiya, I do not expect Maps or Semantic Maps in version 2.x to work with Semantic MediaWiki 1.9.x due to changes to the Validator dependency which ocurred. So probably you will have to wait for a stable release in case you want to avoid development versions. Due to the way MediaWiki handles the autoloading of extensions installed via Composer you are currently forced to use thus installed extensions on all instances of MediaWiki in case your are using a single codebase. So yes there is more complexity to handle a farm and you cannot just do an update via git. Cheers Karsten Am 15.01.2014 16:24, schrieb egel: > James HK schreef op 2014-01-14 22:43: >> Hi, >> >>> We also use Maps and we don't want use unstable or development >>> versions. >> SMW 1.9 has been officially released [1] but developers and users are >> always free and encouraged to submit patches for past and future >> releases. >> >> PS: It might be that some core developers share some of their time (as >> for myself, I don't have time to support legacy releases) to create >> patches for outdated releases (1.8 has been superseded as 1.9 is >> released). >> >> [1] >> http://wikimedia.7.x6.nabble.com/Semantic-MediaWiki-1-9-released-td5019491.html >> >> Cheers >> > So far as I can find, forces upgrading to SMW 1.9 you to upgrade > (Semantic) maps to a unstable / development version. Or is there a way > to use SMW 1.9 and (Semantic) maps 2.0 at the same time? > > Installation of SMW 1.9 needs Composer and because only 2 wiki's on our > wikifarm, http://www.scoutwiki.org , are using Semantic extensions, will > Composer only add more complexities. Or can you still use git to update > SMW? > >> On 1/15/14, egel <eg...@sc...> wrote: >>> Semantic MediaWiki (Versie 1.8.0.5) and MW 1.22.1 breaks uploads of >>> images and saving of edits |
From: Jeroen De D. <jer...@gm...> - 2014-01-15 18:14:39
|
Hey, So far as I can find, forces upgrading to SMW 1.9 you to upgrade > (Semantic) maps to a unstable / development version. > That is correct. Or is there a way > to use SMW 1.9 and (Semantic) maps 2.0 at the same time? > Kgh is correct in stating this will not work. I hope to have Maps 3.0 released in the near future. I also hope that a new release of MediaWiki core is made, that does not mess up compatibility. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 -- |
From: egel <eg...@sc...> - 2014-01-18 21:10:23
|
Hi, I'm running a wikifarm so I'm not going to use composer but I have shell access. Now Maps and Semantic Maps 3.0 are released I have tried first to upgrade Validator with git and I get: Fatal error: Uncaught exception 'Exception' with message 'Validator depends on the ParamProcessor library.' in /services/scoutwiki/htdocs/extensions/Validator/Validator.php:31 I have found "https://github.com/JeroenDeDauw/ParamProcessor" but that doesn't give any usefull information on how to install it. -- Met Vriendelijke Zwerversgroeten Wouter Rademaker |
From: Ralf K. <ral...@kr...> - 2014-01-20 07:25:33
|
Hi, even though I recently managed to update my single wikis using composer, I would propose to add some basic support to manually install extensions like Validator - at least a very basic description how to integrate it. I was facing the same problem with ParamProcessor when I tried the manual git installation. Cheers Ralf On Saturday 18 January 2014 egel wrote: > Hi, > I'm running a wikifarm so I'm not going to use composer but I have shell > access. > Now Maps and Semantic Maps 3.0 are released I have tried first to > upgrade Validator with git and I get: > > Fatal error: Uncaught exception 'Exception' with message 'Validator > depends on the ParamProcessor library.' in > /services/scoutwiki/htdocs/extensions/Validator/Validator.php:31 > > I have found "https://github.com/JeroenDeDauw/ParamProcessor" but that > doesn't give any usefull information on how to install it. |
From: Jeroen De D. <jer...@gm...> - 2014-01-18 23:36:17
|
Hey, You cannot do an old-style manual installation any more for various reasons. The code simply no longer supports it. Why can you not use Composer? Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 -- |
From: egel <eg...@sc...> - 2014-01-19 09:38:23
|
Jeroen De Dauw schreef op 2014-01-19 00:35: > Hey, > > You cannot do an old-style manual installation any more for various reasons. The code simply no longer supports it. Can I call that a bug? When will the support be fixed? > Why can you not use Composer? The 15 wikis in our wikifarm share a single codebase, 3 are using Maps of which 2 are using some Semantic extensions. For various reasons, only those extensions are enabled on a wiki which the wiki really uses, particularly heavy extensions like SMW. > Cheers > > -- > Jeroen De Dauw > http://www.bn2vs.com [1] > Don't panic. Don't be evil. ~=[,,_,,]:3 > -- -- Met Vriendelijke Zwerversgroeten Wouter Rademaker Links: ------ [1] http://www.bn2vs.com |
From: [[kgh]] <med...@kg...> - 2014-01-19 10:45:42
|
Basically everybody running multiple wikis from a single codebase will face this problem if they have heterogeneous configurations. Currently there is not other choice than to split the codebase into homogeneous environments. I already have filed a bug for this [1] since I think there quite some small farms out there facing the same issue. But even for single installs this may add more flexibility I believe. However I do not expect it to be tackled soon, so sit thigh but do not hold your breath. [1] https://bugzilla.wikimedia.org/show_bug.cgi?id=59872 Am 19.01.2014 10:38, schrieb egel: > > > Jeroen De Dauw schreef op 2014-01-19 00:35: > >> Hey, >> >> You cannot do an old-style manual installation any more for various reasons. The code simply no longer supports it. > Can I call that a bug? When will the support be fixed? > >> Why can you not use Composer? > The 15 wikis in our wikifarm share a single codebase, 3 are using Maps > of which 2 are using some Semantic extensions. For various reasons, only > those extensions are enabled on a wiki which the wiki really uses, > particularly heavy extensions like SMW. > >> Cheers >> >> -- >> Jeroen De Dauw >> http://www.bn2vs.com [1] >> Don't panic. Don't be evil. ~=[,,_,,]:3 >> -- |
From: Yaron K. <ya...@wi...> - 2014-01-19 15:42:49
|
Is there any way, theoretically, to disable the inclusion of an extension/library within a Composer-based system? If not, that does sound pretty bad. Maybe a solution could be to have some or all of the Composer-enabled extensions include a manual "disable" setting, like $wgDisableSemanticMediaWiki, that, if set to true, leads the extension to quickly exit out before doing anything. Or maybe there could be an overall global variable, like $wgDisabledExtensions, that takes in an array of names of extensions that should disable themselves... -Yaron On Sun, Jan 19, 2014 at 5:45 AM, [[kgh]] <med...@kg...> wrote: > Basically everybody running multiple wikis from a single codebase will > face this problem if they have heterogeneous configurations. Currently > there is not other choice than to split the codebase into homogeneous > environments. I already have filed a bug for this [1] since I think > there quite some small farms out there facing the same issue. But even > for single installs this may add more flexibility I believe. However I > do not expect it to be tackled soon, so sit thigh but do not hold your > breath. > > [1] https://bugzilla.wikimedia.org/show_bug.cgi?id=59872 > > Am 19.01.2014 10:38, schrieb egel: > > > > > > Jeroen De Dauw schreef op 2014-01-19 00:35: > > > >> Hey, > >> > >> You cannot do an old-style manual installation any more for various > reasons. The code simply no longer supports it. > > Can I call that a bug? When will the support be fixed? > > > >> Why can you not use Composer? > > The 15 wikis in our wikifarm share a single codebase, 3 are using Maps > > of which 2 are using some Semantic extensions. For various reasons, only > > those extensions are enabled on a wiki which the wiki really uses, > > particularly heavy extensions like SMW. > > > >> Cheers > >> > >> -- > >> Jeroen De Dauw > >> http://www.bn2vs.com [1] > >> Don't panic. Don't be evil. ~=[,,_,,]:3 > >> -- > > > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > Semediawiki-user mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > -- WikiWorks · MediaWiki Consulting · http://wikiworks.com |
From: Jeroen De D. <jer...@gm...> - 2014-01-19 15:54:16
|
Hey, Is there any way, theoretically, to disable the inclusion of an > extension/library within a Composer-based system? > Perhaps there is theoretically, as you already provided an approach that would "work". This is however a very bad idea, as it undermines the managing of dependencies. It's like installing some apps via apt-get on your debian box, and then manually deleting some of the libraries apt-get installed. If you want different sets of extensions for different wikis, then use different installations for them. Each one with their own composer.json file, and thus with only the extensions they actually need. You'd need to figure out how to achieve this exactly, though I'm quite sure this is the only approach that will give you sane results. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 -- |
From: Ryan L. <rl...@gm...> - 2014-01-20 09:08:05
|
On Sun, Jan 19, 2014 at 7:53 AM, Jeroen De Dauw <jer...@gm...>wrote: > Hey, > > Is there any way, theoretically, to disable the inclusion of an > > extension/library within a Composer-based system? > > > > Perhaps there is theoretically, as you already provided an approach that > would "work". This is however a very bad idea, as it undermines the > managing of dependencies. It's like installing some apps via apt-get on > your debian box, and then manually deleting some of the libraries apt-get > installed. > > If you want different sets of extensions for different wikis, then use > different installations for them. Each one with their own composer.json > file, and thus with only the extensions they actually need. You'd need to > figure out how to achieve this exactly, though I'm quite sure this is the > only approach that will give you sane results. > > What if the wiki farm has hundreds of wikis, many of which have differences? It would be prohibitively expensive to run this many copies of MediaWiki. Just assuming you only have 10 differences between all of your wikis, you'd need to run 10 copies of MediaWiki. MediaWiki uses a lot of memory and running more than 3-4 copies on a single cluster group is likely to start running you into trouble (wikimedia only has two versions at any given time). Assuming you use 3 with only 10 differences for hundreds of wikis (which is very unlikely), you're looking at three cluster groups. There's also a very high operational cost to running multiple copies of MediaWiki. Deployment becomes a problem, keeping versions in relative sync is a problem, and monitoring and bug reporting is a major problem. That's just scratching the surface. This option isn't viable for large clusters. It's superficially viable for single wikis, but as others have mentioned, disabling an extension is often needed for debugging and also often needed for removing performance issues associated with a single extension. - Ryan |
From: Yaron K. <ya...@wi...> - 2014-01-19 16:18:09
|
Hi, Okay - it's good to know that Composer doesn't natively support such a thing. Given that, I think my idea of flags to tell extensions to disable themselves is a very reasonable idea. I don't see the analogy to deleting libraries here - nothing is getting deleted; this would be a setting to let the code do the "smart" thing based on user preferences. I would think the much closer analogy is downloading Firefox plugins, and then going through and manually enabling or disabling them. For people who run wiki farms and need to run turn various extensions on or off (I'm one of them), the idea of a separate installation for each configuration seems like a non-starter. As soon as there are more than one or two different extensions that can be independently enabled or disabled, the number of different installations to maintain would be unwieldy; especially if there are any local modifications to any of the extensions. -Yaron On Sun, Jan 19, 2014 at 10:53 AM, Jeroen De Dauw <jer...@gm...>wrote: > Hey, > > Is there any way, theoretically, to disable the inclusion of an >> extension/library within a Composer-based system? >> > > Perhaps there is theoretically, as you already provided an approach that > would "work". This is however a very bad idea, as it undermines the > managing of dependencies. It's like installing some apps via apt-get on > your debian box, and then manually deleting some of the libraries apt-get > installed. > > If you want different sets of extensions for different wikis, then use > different installations for them. Each one with their own composer.json > file, and thus with only the extensions they actually need. You'd need to > figure out how to achieve this exactly, though I'm quite sure this is the > only approach that will give you sane results. > > Cheers > > -- > Jeroen De Dauw > http://www.bn2vs.com > Don't panic. Don't be evil. ~=[,,_,,]:3 > -- > -- WikiWorks · MediaWiki Consulting · http://wikiworks.com |
From: Ralf K. <ral...@kr...> - 2014-01-20 07:29:16
|
Hi, I just want to highlight that disabling extensions is also often used by people running single wikis (e.g. for troubleshooting). If everything is included and managed by composer how can that be supported in the future? I also see a lack of flexibility. Cheers Ralf On Sunday 19 January 2014 Yaron Koren wrote: > Hi, > > Okay - it's good to know that Composer doesn't natively support such a > thing. Given that, I think my idea of flags to tell extensions to disable > themselves is a very reasonable idea. I don't see the analogy to deleting > libraries here - nothing is getting deleted; this would be a setting to let > the code do the "smart" thing based on user preferences. I would think the > much closer analogy is downloading Firefox plugins, and then going through > and manually enabling or disabling them. > > For people who run wiki farms and need to run turn various extensions on or > off (I'm one of them), the idea of a separate installation for each > configuration seems like a non-starter. As soon as there are more than one > or two different extensions that can be independently enabled or disabled, > the number of different installations to maintain would be unwieldy; > especially if there are any local modifications to any of the extensions. > > -Yaron > > On Sun, Jan 19, 2014 at 10:53 AM, Jeroen De Dauw <jer...@gm...>wrote: > > Hey, > > > > Is there any way, theoretically, to disable the inclusion of an > > > >> extension/library within a Composer-based system? > > > > Perhaps there is theoretically, as you already provided an approach that > > would "work". This is however a very bad idea, as it undermines the > > managing of dependencies. It's like installing some apps via apt-get on > > your debian box, and then manually deleting some of the libraries apt-get > > installed. > > > > If you want different sets of extensions for different wikis, then use > > different installations for them. Each one with their own composer.json > > file, and thus with only the extensions they actually need. You'd need to > > figure out how to achieve this exactly, though I'm quite sure this is the > > only approach that will give you sane results. > > > > Cheers > > > > -- > > Jeroen De Dauw > > http://www.bn2vs.com > > Don't panic. Don't be evil. ~=[,,_,,]:3 > > -- |
From: Ryan L. <rl...@gm...> - 2014-01-20 09:13:48
|
On Sat, Jan 18, 2014 at 3:35 PM, Jeroen De Dauw <jer...@gm...>wrote: > Hey, > > You cannot do an old-style manual installation any more for various > reasons. The code simply no longer supports it. > > Why can you not use Composer? > > This really sounds like a step backwards. I like that fact that we have a simple mechanism for installing extensions now, but very large numbers of installations use a git workflow for MediaWiki and MediaWiki extension installation. Git workflows have an advantage of working across languages and platforms, making the lives of operations engineers easier. Is there any reason that the versions composer references can't point to specific git tags or commits? It would be pretty ideal for composer to support git directly. - Ryan |
From: Ralf K. <ral...@kr...> - 2014-01-20 09:21:47
|
+1 Initially it was stated that composer CAN be used to install MW extensions. Fine. But now for SMW extensions and dependencies we MUST use it. I also vote strongly for keeping (and supporting) the git ways of working in parallel! Cheers Ralf PS: I am curious how developers do their work with composer testing various commits? On Monday 20 January 2014 Ryan Lane wrote: > On Sat, Jan 18, 2014 at 3:35 PM, Jeroen De Dauw <jer...@gm...>wrote: > > Hey, > > > > You cannot do an old-style manual installation any more for various > > reasons. The code simply no longer supports it. > > > > Why can you not use Composer? > > This really sounds like a step backwards. I like that fact that we have a > simple mechanism for installing extensions now, but very large numbers of > installations use a git workflow for MediaWiki and MediaWiki extension > installation. Git workflows have an advantage of working across languages > and platforms, making the lives of operations engineers easier. > > Is there any reason that the versions composer references can't point to > specific git tags or commits? It would be pretty ideal for composer to > support git directly. > > - Ryan > ---------------------------------------------------------------------------- > -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > Semediawiki-user mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-user |
From: egel <eg...@sc...> - 2014-01-20 20:59:13
|
Hi > Yaron Koren wrote: > Is there any way, theoretically, to disable the inclusion of an > extension/library within a Composer-based system? If not, that does > sound pretty bad. I am testing a way to disable auto-loading of all extensions installed by composer and then loading them (DataValues *, Validator and Maps) by "hand" in LocalSettings.php at http://uk.scoutwiki.org/Test . You need to hack/patch a composer auto-load file after every run of composer. -- Met Vriendelijke Zwerversgroeten Wouter Rademaker |
From: James HK <jam...@gm...> - 2014-01-14 21:43:42
|
Hi, > We also use Maps and we don't want use unstable or development versions. SMW 1.9 has been officially released [1] but developers and users are always free and encouraged to submit patches for past and future releases. PS: It might be that some core developers share some of their time (as for myself, I don't have time to support legacy releases) to create patches for outdated releases (1.8 has been superseded as 1.9 is released). [1] http://wikimedia.7.x6.nabble.com/Semantic-MediaWiki-1-9-released-td5019491.html Cheers On 1/15/14, egel <eg...@sc...> wrote: > Semantic MediaWiki (Versie 1.8.0.5) and MW 1.22.1 breaks uploads of > images and saving of edits > > > -- > Met Vriendelijke Zwerversgroeten > > Wouter Rademaker > > > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > Semediawiki-user mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > |
From: James HK <jam...@gm...> - 2014-01-14 22:11:07
|
Hi, A follow up (Make WikiPage::$mPreparedEdit public) on the reported issue can be found here [1], [2]. [1] https://bugzilla.wikimedia.org/show_bug.cgi?id=60054 [2] https://gerrit.wikimedia.org/r/#/c/107488/ Cheers On 1/15/14, James HK <jam...@gm...> wrote: > Hi, > >> We also use Maps and we don't want use unstable or development versions. > > SMW 1.9 has been officially released [1] but developers and users are > always free and encouraged to submit patches for past and future > releases. > > PS: It might be that some core developers share some of their time (as > for myself, I don't have time to support legacy releases) to create > patches for outdated releases (1.8 has been superseded as 1.9 is > released). > > [1] > http://wikimedia.7.x6.nabble.com/Semantic-MediaWiki-1-9-released-td5019491.html > > Cheers > > On 1/15/14, egel <eg...@sc...> wrote: >> Semantic MediaWiki (Versie 1.8.0.5) and MW 1.22.1 breaks uploads of >> images and saving of edits >> >> >> -- >> Met Vriendelijke Zwerversgroeten >> >> Wouter Rademaker >> >> >> >> ------------------------------------------------------------------------------ >> CenturyLink Cloud: The Leader in Enterprise Cloud Services. >> Learn Why More Businesses Are Choosing CenturyLink Cloud For >> Critical Workloads, Development Environments & Everything In Between. >> Get a Quote or Start a Free Trial Today. >> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk >> _______________________________________________ >> Semediawiki-user mailing list >> Sem...@li... >> https://lists.sourceforge.net/lists/listinfo/semediawiki-user >> > |