Hello. I want to list all pages edited or created at least once after a
given timestamp. API for Recent changes lists every edit and for my
mediawiki exceeds rclimit=5000. What are the possible options to list only
distinct pages changed, not changes?
Requirements: a simple installer and a one click maintainer for all!
<snip />
Completely agree. I think some of the issues we confront here are artifacts of the age of MW (not to be age-ist - I'm an old coot myself). Like PHP, MW has been around a long time, and during that time the principles and paradigms of software development have been advancing. Nobody was thinking about encapsulation or dependency injection in the old days; today nobody would write software without holding those principles in high respect. Some of ttoday's complexity issues arise from our insistence on backward compatibility. Even at PHP 5+ most of the PHP code we wrote in the 1990's will still run, and I find that amazing. I've replaced appliances and automobiles more recently that some of my ancient computer code! So how do we move forward toward a simpler and more elegant design?
First, we ought to learn from our colleagues who are pushing the technology successfully. To this end, I would like to gently nudge the Foundation in the direction of the PHP-FIG. You can't get more smarts in a room than you can with the fellows of PHP-FIG. They are thinking about packaging and deployment issues all the time, across a wide range of platforms and applications, and they have good ideas to share. Jeroen is represented among them, and I believe that the Foundation should be represented, too.
Second, we should be present and engaged at the major PHP conferences. At PHP World 2015 we had Laravel, Drupal, Cake, Magento, Symfony, Joomla, Zend, WordPress and others, but not us. MediaWiki and Wikipedia are towering influences on knowledge management in the 21st century. There is no reason to hide our light under a bushel; we should be "out there" in a manner commensurate with our world importance. WordPress correctly notes that it accounts for 25% of all internet traffic. I would suggest that Wikipedia accounts for more than 25% of the _useful_ internet traffic!
Third, we should at least consider the idea of a one-time breaking change, when it enables true progress. The PHP community has done this with the release of PHP7. The most egregious language artifacts of bygone days have been cast aside. All new PHP software has an improved chance to be more secure and performant, and to avoid the propagation of antipatterns and antipractices. If we can put such an idea into the conversation about MediaWiki, we would want to approach it with a crystal clear vision of the value we seek to achieve. A simple installer and maintainer would be worth such a change. I would also add that we could improve our Extension management, and this could be considered in concert with a simple installer and maintainer.
Fourth, we can learn a lot from the Code-Is-Poetry group at WordPress. Like MediaWiki, WordPress is an old software platform. But they have somehow kept a freshness in their community. I think we share a lot of their values and may be able to emulate some of their successes. They've got the simple install thing nailed!
Best regards to all,
Ray
Hi all,
Tomorrow we will be issuing a security release for all branches
of MediaWiki 1.23 and beyond.
The new releases will be:
1.23.12
1.24.5
1.25.4
1.26.1
Fixes will be available in the affected release branches and master.
Tarballs will be uploaded for the indicated point releases as well.
This release encompasses 6 fixes for core only, no bundled extensions
are impacted.
Have a great day,
Chad H. & Chris S.
_______________________________________________
MediaWiki announcements mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce
Hey I've been struggling for a few days to configure my 1.26 MW to use
visual editor with HTTPS enabled.
My server is running NGINX on Debian, I have installed the native Parsoid
package and configured my settings.js and LocalSettings.php as follows:
http://hastebin.com/ixebuhunot.coffee
Parsoid works as expected and will render pages as per:
http://psychonautwiki.org:8142/pw/
However when trying to edit pages using Visual Editor in MediaWiki, I get
an error like: MediaWiki-API-Error:(curl error: 35) SSL connect error.
>From the docs, I can't figure out what the issue is and hope that somebody
else has encountered this before.
I've left it enabled in case anybody can take a look at the console and
find any clues (I don't know what I'm doing)
Much appreciated.
--
Love and waffles,
P. Josepherum | http://psychonautwiki.org/
Executive summary: "A large majority of users agree that upgrading MW
is way too much of a pain"
--
-------------------------
M. Feldman
Vigil Health Solutions, Inc.
2102 - 4464 Markham Street
Victoria, BC
Canada V8Z 7X8
Tel: 250-383-6900
Hi all,
I am trying to set up Visual Editor on our MediaWiki 1.26 installation (running on Ubuntu 15.04 LAMP stack, VisualEditor release REL1_26). I have set up Parsoid on a separate machine, from the Debian package (version 0.4.1), linked it to my MediaWiki instance, and it works - for instance, invoking http://test-apps.km.cimpress.net:8142/vdanilchenko-corewiki/v3/page/html/Pa… correctly retrieves and parses the contents of my 'Parsoid' wiki page.
The problem is on the Wiki side. I have downloaded and installed Visual Editor, loaded the submodule, and configured LocationSettings.php correctly, as far as I can tell:
require_once "$IP/extensions/VisualEditor/VisualEditor.php";
$wgDefaultUserOptions['visualeditor-enable'] = 1;
$wgHiddenPrefs[] = 'visualeditor-enable';
$wgDefaultUserOptions['visualeditor-enable-experimental'] = 0;
$wgVirtualRestConfig['modules']['parsoid'] = array(
'url' => 'http://test-apps.km.cimpress.net:8142',
'domain' => 'vdanilchenko-corewiki',
'prefix' => 'vdanilchenko-corewiki'
);
However, when I hit 'edit' while viewing a page, 3 things happen:
1. Visual Editor fires up, but the 'Save page' button is greyed out. I can edit the text, but not save it.
2. All template and function calls are expanded and editable as literal text, which is of course totally wrong.
3. The following errors get logged in the console, the 1st one 4 different times with slightly different call stacks (the original invoker being at anonymous function at ve.ui.LinkContextItem.js:27, ve.ui.LinkContextItem.js:27, ve.ui.ToolbarDialogTool.js:24, and ve.ui.LanguageInspectorTool.js:19 respectively):
Uncaught TypeError: Expecting a function in instanceof check, but got undefined oojs.jquery.js:93
undefinedoo.inheritClass @ oojs.jquery.js:93
(anonymous function) @ ve.ui.LinkContextItem.js:27 (this is the part that varies)
Uncaught TypeError: Cannot read property 'static' of undefined ve.ce.Surface.js:376
ve.ce.Surface.getSelection @ ve.ce.Surface.js:376
ve.ce.Surface.focus @ ve.ce.Surface.js:429
(anonymous function) @ ve.init.mw.DesktopArticleTarget.js:361
Can anyone help me out, let me know what I am doing wrong, or what I am missing?
> From: Tim Starling <tstarling(a)wikimedia.org>
All good points, and yet:
> Your case is not normal. That
> is the price you pay for upgrading MediaWiki as often as other people
> paint their houses.
That's a useful analogy. One doesn't hire a staff painter to be on-hand, touching up little nicks here and there as they develop over time unless painting is but a small part of the operation. For most people, one waits until it actually needs painting.
I have farm plants and animals to take care of, and a not-for-profit organization to run, and I volunteer for numerous other organizations. I don't have time to baby-sit a computer.
This is not an easy thing to hear nor understand for those who spend all their time baby-sitting computers for a living. I know -- that was me in another life!
So, one *could* say, "Hey, if we made upgrading as easy as paint drying, more people would keep up!"
Or one can self-righteously blame the victim for having a life beyond keeping up with every little upgrade.
(Postscript: I composed that message a week and a day ago. Then I felt guilty, and proceeded to go on an "upgrade binge," bringing my OS up from 10.6.8 to 10.10.5, which would have given me -- among other things -- PHP 5.6. End result: my email and website were down for a week as I struggled to get my server's environment back, and I never did get a working upgrade installed. This is coming to you from a restored backup. I feel vindicated.)
Jan Steinman
EcoReality Co-op, http://www.EcoReality.org
2152 Fulford-Ganges Road
Salt Spring Island, BC V8K 1Z7 CANADA
+1 250.653.2024
The MediaWiki Stakeholders' User Group wants to improve MediaWiki and advocates the needs of MediaWiki users outside Wikimedia Foundation-supported projects.
But who is using MediaWiki? In an effort to answer this question the MediaWiki Stakeholders’ Group organized a survey during the summer of 2015 and asked people using MediaWiki to respond. The result is a sampling of over 100 responses from people using MediaWiki around the world. The results were interesting. Folks from all sorts of communities and industries use MediaWiki - from organizations like NASA, The UK LGBT Archive, Society of Exploration Geophysicists, and more.
Combined with some statistics we were able to obtain with help from individuals at the WMF, and the results of the survey we have completed our MediaWiki Usage Report for 2015 . This report provides insight into the various ways MediaWiki is being used - How people upgrade, what extensions are their "must have's", what they enjoy about the software, their concerns, and more. We encourage those using MediaWiki to have a look and provide any feedback or thoughts.
If you'd like to know more about the MediaWiki Stakeholders' Group, or to get involved, join us for one of our regular hangouts or leave a note on our talk page . MediaWiki Wishlist
Combined with existing collaboration around request features and responses from one particular survey question, "What would you like to see most improved in MediaWiki the software?" we created a prioritized 'wishlist' of MediaWiki features . Our next project is figuring out how to implement these requests. See Also
* A raw download of the survey results (anonymized of course) can be found on MediaWiki.org
* If you were at our session at Wikimania 2015, this might sound familiar. There we shared preliminary results from the survey while we were still collecting responses.
Brian Wolff <bawolff(a)gmail.com> writes:
> Umm, where is the link to the report?
Dadgummit. Stupid mailmain filtering out HTML mail.
I'll resend. Sorry for the confusion.
Mark.
Hi,
We have one wiki A with thousands of users and one wiki B with a few users.
We want to have a shared database for the user, preferably the easy way as described on https://www.mediawiki.org/wiki/Manual:Shared_database.
What would be the appropriate way to go here:
- Create a separate database, copy the user table from wiki A to that database, do something with the wiki B users, and configure both wiki's to use that shared database.
- Use database of wiki A as shared database and explain that to wiki B
- Think of something else because it is not possible to have shared database with existing wiki's
The first scenario would be the preferred one and I would like to understand if and how that could work.
Thanks! Ad