Why have the idiosyncratic one-point-X naming anyway? "MediaWiki 30.0" sounds much better than "MediaWiki 1.30.0". The mythical "Phase 4" software probably isn't coming out until after Hell freezes over (according to Meta, Phase 4 was supposed to come out in 2004; Duke Nukem Forever was released in 2011 - still no Phase 4; Brian said that MW2.0 was under development in 2013; the Cubs won the World Series in 2016 - still no MW2.0), and if Phase 4/MW2.0 somehow gets developed before the end of the decade, the community will inevitably protest (remember Superprotect?) and fork the last Phase 3/1.x version into a new wiki software package with a different name (a la Firefox/Pale Moon), leaving Phase 4/2.x to rot; therefore, leaving the digit "one" and the decimal point in front of the number is effectively pointless.
Talk:MediaWiki 2.0
Current mediawiki default interface (Skin), installer are obsolete in real way. Any new plans including latest php 7.2 features and a full refresh to the ui, mostly mobile oriented are expected.
Some thoughts
I posted most of this to Wikitech-l. Normally, I wouldn't copy that post here, but since there is no discussion of this page yet, I thought it couldn't hurt and might create some ideas for future discussion. Note, these thoughts are not proposals. They are ideas that may or may not make sense. My objective is to get a discussion going.
Create MW 2.0
Pros
- Improving the application architecture.
- Utilizing more client side resources, thereby reducing the server side resource requirements.
- Clean up and improve existing services.
Cons
- Rewrites of major applications normally fail because they become overly ambitious.
Change the parser
- Get rid of mediawiki markup and move to html with embedded macros that are processed client side.
- Move extension processing client side.
- Replace templates with a cleaner macro-based language (but, KISS).
Pros
- Reduce server side resource requirements, thereby reducing server side costs. Server side becomes mostly database manipulation.
- Make use of the far larger aggregate resources available on client side (many more client machines than server machines).
- With macro processing client side, debates about enhancements to parser extensions that require more processing shift to looking at client side.
- Allows development of a parser driven by well-defined grammar.
Cons
- Unclear whether it is possible to move all or most parser processing to client side.
- Would need a (probably large and complex) transition application that translates mediawiki markup into new grammar.
- Since not all clients may have the resources to expand macros and do other client side processing in a timely manner, may need to provide server side surrogate processing based on either user selectable (e.g., preferences) choice or automatic discovery.
- Need to select client side processing engine (e.g., Javascript, Java), which may lead to major developer fighting.
Clean up security architecture
- Support per page permissions, ala' Unix file system model.
- Integrate authentication with emerging global services (e.g., OpenID) without use of extensions.
- Move group membership definition out of LocalSettings into database table.
Pros
- Chance to think through security requirements and craft clean solution.
- Offload most authentication processing and login data protection to service providers that more sharply focus on its requirements.
- Some customers have expressed interest in per page permissions.
Cons
- Changing security architectures is a notoriously difficult objective. Most attempts lead to bloated solutions that never work in practice.
- Some developers oppose per page permissions.
- Would need to develop WMF standards that authentication providers must meet before accepting them for WMF project login.
There are other things that MW 2.0 could do that might be discussed, such as:
- Change the page history model. When page is flagged stable, subsequent page changes occur to new draft page. Provide link to draft page on stable page.
- Think through how to support multiple db backends so application development doesn't continually break this support.
A collaborative Editor is a Must. Non Destructive Editing.
The Idea is a person can start an article. Send Links to friends. People can join into the edit session. Then create an article collaboratively.
Its like together JS
A chat window is a must
All the edits, discussions everything is recorded on the wiki timeline --~~~~
I'm sure a visual editor is also a goal for this release.
Well given this page is describing something imaginary, sure why not. Don't forget the unicorns and ponies too ;)
Less imaginary now. :-)