Would it be possible to adapt the Visual Editor to run under 1.19?
I have a couple of reasons for wanting that:
* 1.19 is our LTS release. Visual Editor looks awesome and I'd like to provide people who are stuck on older versions of MediaWiki with a persuasive reason to upgrade to 1.19 at least.
* FCKeditor is no longer supported for MediaWiki, but people are still using it and, for some reason, like what it provides. If we can make the Visual Editor available to them, I'm hoping the need for FCKeditor will disappear.
There is a dependency on Parsoid and node.js, of course, that a FCKeditor doesn't need, but I'm assuming right now that if MediaWiki works with the extension, then the Parsoid instance will just run.
I'll be setting up and testing Visual Editor soon and start looking at what is needed to get it running against 1.19 and begin to see how feasible that even is.
Is anyone else interested in helping to make this happen?
On 4 January 2013 17:02, Mark A. Hershberger mah@everybody.org wrote:
Is anyone else interested in helping to make this happen?
I have no coding ability but would LOVE this for our work 1.19 instances, and would be most pleased to test.
- d.
On Fri, Jan 4, 2013 at 10:04 AM, David Gerard dgerard@gmail.com wrote:
On 4 January 2013 17:02, Mark A. Hershberger mah@everybody.org wrote:
Is anyone else interested in helping to make this happen?
I have no coding ability but would LOVE this for our work 1.19 instances, and would be most pleased to test.
I think it would be valuable to have a coordinated effort to test Visual Editor at a time when such a project could provide useful feedback to the VE development team.
-Chris
On 01/04/2013 09:02 AM, Mark A. Hershberger wrote:
There is a dependency on Parsoid and node.js, of course, that a FCKeditor doesn't need, but I'm assuming right now that if MediaWiki works with the extension, then the Parsoid instance will just run.
This should be the case. Parsoid only interacts with MediaWiki through long-established web API calls, so should be compatible with very old MediaWiki versions.
Am 04.01.2013 18:02, schrieb Mark A. Hershberger:
- FCKeditor is no longer supported for MediaWiki, but people are still
using it and, for some reason, like what it provides. If we can make the Visual Editor available to them, I'm hoping the need for FCKeditor will disappear.
Hi Mark, and users of FCKeditor
- regarding the FCKeditor and the extension https://www.mediawiki.org/wiki/Extension:FCKeditor_%28by_Mafs%29 which I co-authored many years ago, but stopped using it -
I must warn users, because the FCKeditor as such has known security issues.
These (some are severe) issues can quickly be spotted by a search with your favorite search engine, results are like http://www.cvedetails.com/vulnerability-list/vendor_id-2724/Fckeditor.html
On 01/04/2013 01:26 PM, Thomas Gries wrote:
I must warn users, because the FCKeditor as such has known security issues.
Even more reason for us to get VE working against 1.19. I saw that some people have added instructions for FCKeditor on 1.19, but VE would be much more compelling if we can get it working.
Am 04.01.2013 19:57, schrieb Mark A. Hershberger:
Even more reason for us to get VE working against 1.19. I saw that some people have added instructions for FCKeditor on 1.19, but VE would be much more compelling if we can get it working.
Yes!
Switching between MediaWiki Wiki syntax and the FCKeditor WYSIWYG method created so often problems, and one often misses many of the advanced Wiki syntax and parser function s --- that I simply decided to disable the FCKeditor for all my users
On 4 January 2013 09:02, Mark A. Hershberger mah@everybody.org wrote:
Would it be possible to adapt the Visual Editor to run under 1.19?
Possible? Yes. However, it would involve back-porting a number of changes that have been made to core since then (and will no-doubt continue to be added as we discover new ways in which MW assumes that "editing" and "EditPage.php" are the same thing). For some quick examples, and https://gerrit.wikimedia.org/r/#/c/36237/ and https://gerrit.wikimedia.org/r/#/c/37191/ (which are both in 1.21 wmf5) - though I'm sure there are more out there. I worry that you'd end up needing to create 1.19.4-ve_support branches that would be no easier than pushing to a 1.21 bleeding-edge branch, sadly.
I have a couple of reasons for wanting that:
- 1.19 is our LTS release. Visual Editor looks awesome and I'd like to
provide people who are stuck on older versions of MediaWiki with a persuasive reason to upgrade to 1.19 at least.
Understood (though I didn't know about 1.19 being an LTS release; who is doing the supporting, exactly, and what does 'support' entail here? [*] is unclear…).
However, VE is very much in alpha at this stage, and we do not generally recommend MediaWiki sysadmins trying to install it if they're not running the kind of setup that is pulling 1.21 pre-branches from git every now and then; it's far too likely that VE will have serious bugs that our fortnightly pushes will need to fix, let alone the improvements and new features we'll (hopefully!) be releasing quite frequently. By the time VE is stable enough to recommend, we will probably have a new LTS release by then (indeed, how does that get determined?).
- FCKeditor is no longer supported for MediaWiki, but people are still
using it and, for some reason, like what it provides. If we can make the Visual Editor available to them, I'm hoping the need for FCKeditor will disappear.
As a former sysadmin of an FCKeditor-using MW installation, I too look forward to the point when VE is sufficiently stable and functional that it's included in the default tarball, and FCK is no longer considered by anyone. :-)
There is a dependency on Parsoid and node.js, of course, that a FCKeditor doesn't need, but I'm assuming right now that if MediaWiki works with the extension, then the Parsoid instance will just run.
As Gabriel said, Parsoid's dependencies on MediaWiki are a lot less bleeding-edge (at least, right now), and mostly use the long-established APIs. It's possible that this will change in future, though of course we'd rather avoid this if we can.
I'll be setting up and testing Visual Editor soon and start looking at what is needed to get it running against 1.19 and begin to see how feasible that even is.
Is anyone else interested in helping to make this happen?
[*] - https://www.mediawiki.org/wiki/Requests_for_comment/Tarball_maintenance
J. -- James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc.
jforrester@wikimedia.org | @jdforrester
On 9 January 2013 00:08, James Forrester jforrester@wikimedia.org wrote:
Understood (though I didn't know about 1.19 being an LTS release; who is doing the supporting, exactly, and what does 'support' entail here? [*] is unclear…).
Tarball version is "supported" (security fixes, etc) for the purpose of not having hideously ancient unsupportable rubbish in Debian therefore Ubuntu, and oh yeah other distros. And working with the distro package maintainers not to do weird broken things with their version of MediaWiki, i.e. Debian therefore Ubuntu.
- d.
On 01/08/2013 07:08 PM, James Forrester wrote:
On 4 January 2013 09:02, Mark A. Hershberger mah@everybody.org wrote:
Would it be possible to adapt the Visual Editor to run under 1.19?
Possible? Yes. However, it would involve back-porting a number of changes that have been made to core since then
Oh, so it's just a small matter of programming!
...
Still, the two changes you highlighted (http://hexm.de/og) are not too discouraging, at least after my first glance. I'll want to talk to Roan and Trevor to see how crazy they think this idea is. Since a few other people have already expressed interest (on and off list), I think it is worth pursuing for a little while.
I worry that you'd end up needing to create 1.19.4-ve_support branches that would be no easier than pushing to a 1.21 bleeding-edge branch, sadly.
I've no doubt that providing reasonable LTS support for MW would involve backporting some things. I've already seen where this is needed to support MobileFrontend on 1.19 for example.
But this sort of work is needed if we are serious about providing software that is appealing to users outside of the WMF. Of course, then we have to rely on non-WMF resources to accomplish this since supporting third party MW users isn't part of the core vision or values of the WMF.
Understood (though I didn't know about 1.19 being an LTS release; who is doing the supporting, exactly, and what does 'support' entail here? [*] is unclear…). [*] -
https://www.mediawiki.org/wiki/Requests_for_comment/Tarball_maintenance
David Gerard seems to understand what I meant, but let me flush it out a bit more.
If you look at the survey of wikis that Daniel Zahn has collected on WikiStats (http://wikistats.wmflabs.org), you can see most wikis run on older versions.
I've contacted a few of the oldest ones and gotten them to upgrade. I've even helped a couple with the process.
Some older -- but moderately active -- wikis are hesitant to upgrade because they aren't sure how to handle of the modifications they've made.
This isn't the fault of the WMF or of MediaWiki developers, but for those of us who are interested in wikis other than the WMF's and our own personal wikis, it represents an opportunity.
Part of that opportunity can be met by providing third party users of MW with a relatively stable base to run their site on. Instead of an unpredictable upgrade cycle with disruptive changes (I've had to do s/tooltipAndAccesskey/tooltipAndAccesskeyAttribs/g too many times http://hexm.de/oh), MW developers can work to provide something more manageable.
The LTS version will not only help us to support Debian users (something we haven't wanted to commit to in the past), but also the individual with xyr own installation that wants something secure and upgradeable without too much hassle. Incidentally, larger users without a staff dedicated to wiki maintenance want this as well.
As I said, though, I don't expect WMF resources for this. If they're willing to help with security fixes, I'll be extremely happy. But if that is beyond their scope, then I'll find another source or do it myself.
Thanks,
Mark.
But some changes were hard to adapt, for example at some point the definition of SpecialPage::userCanExecute() changed from public function userCanExecute( $user )
to
public function userCanExecute( User $user ) with typecheck. Then extension's special pages that inherited from SpecialPage and override ::userCanExecute() throwed PHP error about incompatible declaration.
It would be better to check $user instanceof User in SpecialPage code itself, but who cares. Dmitriy
9 Январь 2013 г. 4:09:21 пользователь James Forrester (jforrester@wikimedia.org) написал:
On 4 January 2013 09:02, Mark A. Hershberger mah@everybody.org wrote:
Would it be possible to adapt the Visual Editor to run under 1.19?
Possible? Yes. However, it would involve back-porting a number of changes that have been made to core since then (and will no-doubt continue to be added as we discover new ways in which MW assumes that "editing" and "EditPage.php" are the same thing). For some quick examples, and https://gerrit.wikimedia.org/r/#/c/36237/ and https://gerrit.wikimedia.org/r/#/c/37191/ (which are both in 1.21 wmf5) - though I'm sure there are more out there. I worry that you'd end up needing to create 1.19.4-ve_support branches that would be no easier than pushing to a 1.21 bleeding-edge branch, sadly.
My own (already past) experience of developing MediaWiki extensions shows that it is much easier to keep the compatibility layer in extension itself rather than backporting large changes into older versions of core. For example, one of the gerrit patches mentioned above can be "probed" via method_exists( $this->mTitle, 'getEditNotices' ), then acting according to result - pretty fast and efficient. So, the extensions should be LTS first, not core. The very core of MediaWiki (at least when deployed at small sities) is still revision / article / title, which is possible to use in very similar ways.
However there are major milestone versions, such as 1.17 with ResourceLoader and 1.21 with ContentHandler, and it's not easy to backport their functionality back (although I managed to load dynamically some jQuery scripts in 1.15 with Lab.js loader). So, the extensions probably has to be compatible to such "major milestone versions".
But many of the sites the wikistats list have are quite large and thus earn enough of money to their owners. I wonder why do not they update their sites. One guess I know that some admins consider newer versions are slower than old ones, do not know how much that is true.
Dmitriy
On 01/14/2013 01:34 AM, Dmitriy Sintsov wrote:
My own (already past) experience of developing MediaWiki extensions shows that it is much easier to keep the compatibility layer in extension itself rather than backporting large changes into older versions of core.
This does point to another possible way to backport the changes -- some sort of compatibility extension. That allows the core to remain stable, but allows people to use some newer extensions if they need the features.
However there are major milestone versions, such as 1.17 with ResourceLoader and 1.21 with ContentHandler, and it's not easy to backport their functionality back [...]. So, the extensions probably has to be compatible to such "major milestone versions".
Agreed. 1.19 is (in retrospect) a good choice for an LTS version since ResourceLoader has stabilized somewhat.
But many of the sites the wikistats list have are quite large and thus earn enough of money to their owners. I wonder why do not they update their sites.
"Don't fix what isn't broke" is probably part of the thinking.
One guess I know that some admins consider newer versions are slower than old ones, do not know how much that is true.
Mariya Miteva [[mw:User:Mitevam]] is talking to non-WMF users of MediaWiki and has found that some people are put off by the difficulty of upgrading MediaWiki.
For example, many people have put in some effort to modify a skin for their needs only to find gratuitous changes in the core made with (what appears to be) little thought for backwards compatibility.
So, if a site is working for me as it is, and the only reasons for me to upgrade are some obscure security issues that I may never face, then I will probably find a way to work around the issues instead of upgrading.
14 Январь 2013 г. 19:59:01 пользователь Mark A. Hershberger (mah@everybody.org) написал:
On 01/14/2013 01:34 AM, Dmitriy Sintsov wrote:
My own (already past) experience of developing MediaWiki extensions shows that it is much easier to keep the compatibility layer in extension itself rather than backporting large changes into older versions of core.
This does point to another possible way to backport the changes -- some sort of compatibility extension. That allows the core to remain stable, but allows people to use some newer extensions if they need the features.
I am not sure Wikimedia would like to put their efforts on this. In fact, if I was in Wikipedia, why would I spend my time helping lazy competitors? Wikimedia is too major and MediaWiki is primarily their tool which they generously offer to another people. It should be much simpler to persuade extension-level LTS.
However there are major milestone versions, such as 1.17 with ResourceLoader and 1.21 with ContentHandler, and it's not easy to backport their functionality back [...]. So, the extensions probably has to be compatible to such "major milestone versions".
Agreed. 1.19 is (in retrospect) a good choice for an LTS version since ResourceLoader has stabilized somewhat.
But it misses ContentHandler. And there was a lot of 1.17 installations as well. But yes, 1.17 does not support some things, like specifying to load css on top. Maybe more.
But many of the sites the wikistats list have are quite large and thus earn enough of money to their owners. I wonder why do not they update their sites.
"Don't fix what isn't broke" is probably part of the thinking.
My own experience shows that most of site owners are quite greedy people. Maybe I am bad at business though.
One guess I know that some admins consider newer versions are slower than old ones, do not know how much that is true.
Mariya Miteva [[mw:User:Mitevam]] is talking to non-WMF users of MediaWiki and has found that some people are put off by the difficulty of upgrading MediaWiki.
For example, many people have put in some effort to modify a skin for their needs only to find gratuitous changes in the core made with (what appears to be) little thought for backwards compatibility.
Skins are horrorful part of MediaWiki. They are deliberately made too much low-level to run fast (they probably sample performance). However after upgrade custom skinning could break or miss newly added parts. Daniel Friesen attempted to make skins template-based but I do not think it was accepted into the core.
So, if a site is working for me as it is, and the only reasons for me to upgrade are some obscure security issues that I may never face, then I will probably find a way to work around the issues instead of upgrading.
Maybe, somewhat. Dmitriy
(CC'd mediawiki-enterprise since it is relevant.)
On Mon 14 Jan 2013 11:56:50 AM EST, Dmitriy Sintsov wrote:
This does point to another possible way to backport the changes -- some sort of compatibility extension. That allows the core to remain stable, but allows people to use some newer extensions if they need the features.
I am not sure Wikimedia would like to put their efforts on this.
Agreed. I didn't say they should.
The WMF is focused on its vision (which doesn't include supporting non-WMF users of MW). In the mean time, they've made this software available for the world to use.
My own experience shows that most of site owners are quite greedy people. Maybe I am bad at business though.
People are people.
We're slipping off topic here, but in as far as this relates to users of MediaWiki, I'll continue.
First, I should say that I've worked closely with people across the spectrum of business. I've worked with, and count as friends, several small business owners who run on-line sites as their core business.
On the other "side", I have friends who work at or run non-profits or charities including some at the WMF.
My friends who are site owners are, on the whole, no more self-interested than any of my other friends. They are focused on maintaining the business just as my friends at the WMF is focused on keeping Wikipedia and its sister sites running.
If we want something more from MediaWiki, we can ask the WMF for it, but, since we have the GPL license on the software, we are also empowered to do it ourselves if the WMF is not interested in helping.
Semantic MediaWiki is a great example of this happening and many non-WMF users of MediaWiki use SMW.
I think MediaWiki core alone can (and does!) benefit many people outside the Foundation in just the same way that SMW does. We have the power to make it more suitable for our own non-WMF uses.
On Mon, 14 Jan 2013 08:56:50 -0800, Dmitriy Sintsov questpc@rambler.ru wrote:
14 Январь 2013 г. 19:59:01 пользователь Mark A. Hershberger (mah@everybody.org) написал: On 01/14/2013 01:34 AM, Dmitriy Sintsov wrote:
One guess I know that some admins consider newer versions are slower than old ones, do not know how much that is true.
Mariya Miteva [[mw:User:Mitevam]] is talking to non-WMF users of MediaWiki and has found that some people are put off by the difficulty of upgrading MediaWiki. For example, many people have put in some effort to modify a skin for their needs only to find gratuitous changes in the core made with (what appears to be) little thought for backwards compatibility.
Skins are horrorful part of MediaWiki. They are deliberately made too much low-level to run fast (they probably sample performance). However after upgrade custom skinning could break or miss newly added parts. Daniel Friesen attempted to make skins template-based but I do not think it was accepted into the core.
No... I never finished. Said system is still incomplete, in bits, pieces, and documents full of plans.
Dmitriy
On 01/15/2013 07:25 AM, Daniel Friesen wrote:
Daniel Friesen attempted to make skins template-based but I do not think it was accepted into the core.
No... I never finished. Said system is still incomplete, in bits, pieces, and documents full of plans.
Where is your current work? This is one of the most obvious pain point for many users.
Would you be interested in getting some help with this?
wikitech-l@lists.wikimedia.org