On Mon, Mar 26, 2012 at 12:50, Maximilian Doerr <cybernet678(a)yahoo.com> wrote:
> I strongly disagree with removing wiki text. Several thousand bots depend
> on it. Especially Cluebot NG which is a highly sophisticated anti-vandalism
> bot. I recommend going our current route where the visual editor writes the
> Wikimarkup realtime and vice versa.
I suspect maybe you didn't understand Daniel's message? (or didn't
read it?) I imagine most pages will still use the same markup we have
today after his idea is implemented.
For the pages that are different, the bots can and should adapt.
-Jeremy
For awhile we've supported automatic detection guessing if the webserver
supports PATH_INFO and if so automatically using /index.php/$1 for the
article path. I believe this even predates our better REQUEST_URI handling.
I'm considering the idea of dropping support for this automatic setup.
There are a few faults to this feature we have.
Firstly there are cases where it may break. And I don't mean simple
graceful breakage. I mean it is possible for us to detect support
incorrectly on a slightly misconfigured webserver setup and when that
happens we outputs a fatal page telling the user they have to add some
config to their LocalSettings.php in order to get their wiki to even work.
So you can end up installing MediaWiki, following the "enter your wiki"
link, and end up on a big white plaintext page telling you your wiki was
broken from the start.
It can also cause problems when you change hosting. We detect this
automatically based on whether the current server supports it. This isn't
like short urls where the user sets up the configuration and practically
every single server that exists will support configuring it. In this case
because we auto-detect it if you move from a server setup that supports
/index.php/Foo and then move to something using say FastCGI where it
doesn't work by default all of a sudden your urls change. And not just
change, every url that people have bookmarked becomes invalid.
And of course it creates a bit of a negative incentive. Because
/index.php/Foo is so simple and works out of the box people lazily don't
bother to setup proper short urls. The short url they have is only
slightly shorter. It 'still' is hardwired to architectural facts like the
filesystem and the fact we're using .php.
----
So I'm considering dropping this automatic feature.
Making this change will mean that MediaWiki will start outputting
/index.php?title=... style URLs for everyone who hasn't configured short
urls.
A few important notes:
- This will NOT break existing wikis. We may still leave the actual
fallback PATH_INFO detection in place. And REQUEST_URI will always keep
the implied /index.php/$1 inside the PathRouter. So even though we won't
be outputting /index.php/Foo style urls if the wiki previously supported
/index.php/Foo all those urls will still point to the pages. The links we
output will just start using ?title=.
- While we won't be doing anything automatic anymore anyone obsessed with
having /index.php/Foo can still simply set `$wgArticlePath =
"/index.php/$1";` if it works on their server.
----
What are peoples thoughts on this plan?
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Hi Sumanah
Did you recieved the mail I sent to u regarding my extension to synchronize
video with other content?
By the way I am hoping to hear soon from James regarding Integrating "who's
been awesome?" to MediaWiki.
Thanks
Undergraduate Computer Science and Engineering
University of Moratuwa
Student Member IEEE
Hi,
There's something in Gerrit that i still don't get, even after trying
to ask this several times on mediawiki.org [1] and on IRC. I sincerely
thank everyone who took the time to reply, but either i still
misunderstand the replies or i do understand them and I Just Don't
Like It [2].
Let's consider a patch set i submitted:
https://gerrit.wikimedia.org/r/#change,3361 .
The patch set as i submitted it was not perfect and Aaron marked it
"-1". So far, so good. Then Hashar amended the patch set and
Nikerabbit amended it some more. Now here's what i don't like: The
diffs of their changes show all the changes instead of just showing
Hashar's and Nikerabbit's changes. This is somewhat similar to how we
review patches by new volunteer developers - if the patch attached to
a Bugzilla is not perfect we ask to write a whole new one. That's the
custom, and maybe it's considered educational, but actually its
usefulness is doubtful. Despite this, it is now applied to all the
commits.
Now honestly, the result in the story of this particular patch set is
OK. The resulting patch is better than the first one and the
collaboration worked well. But does this scale? This patch set changes
only a few lines of code; what will happen with patch sets in which
dozens of lines are changed? These happen very often. The reviewer
will have to re-read all the changed lines for every amend and this
looks like a huge waste of time.
It would make a lot more sense to me to see these three changes as a
branch with three commits - the first one is mine, the second one is
Hashar's fix and the third one is Nikerabbit's fix. When there's
agreement that the tip of the branch is good, it's merged to the
master branch. If a reviewer wants to see the whole end-to-end diff,
it's not hard. Mind you, this has nothing to do with SVN - in SVN
branches are used rarely. This, to the best of my understanding, is
the Git way. Git makes this sensible scenario easy, and it is used
successfully in Github - but in the Gerrit workflow this scenario is
not used. I tried reading the Gerrit manual [3] and it didn't make it
any clearer. Yet again, i may be misunderstanding something, so
correct me if i'm wrong; It's really weird that a tool that makes code
review so central makes it a lot harder, too. But that's the feeling
that i get.
Am i just wrong in my understanding of Gerrit?
Am i the only one who doesn't like it?
Is it too late to complain?
[1] https://www.mediawiki.org/wiki/Talk:Git/Workflow
[2] As in https://en.wikipedia.org/wiki/Wikipedia:IDONTLIKEIT .
[3] http://gerrit-documentation.googlecode.com/svn/Documentation/2.2.2/index.ht…
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
>For awhile we've supported automatic detection guessing if the webserver
>supports PATH_INFO and if so automatically using /index.php/$1 for the
>article path. I believe this even predates our better REQUEST_URI handling.
>
>I'm considering the idea of dropping support for this automatic setup.
[..]
I don't really like the idea of dropping it, unless our detection of
it not working really does suck. Moving servers is going to break
things no
matter what. This is especially true now that $wgServer is set
explicitly instead of auto-detected.
If we're worried about auto-detection failing, we could do better
auto-detection in the install script ( Make an ajax request to some
script /mw-config/path_info.php/test and see if it can properly
extract the path info).
-bawolff
Hi.
There are over a dozen reports of general slowness with the English
Wikipedia:
https://en.wikipedia.org/w/index.php?oldid=483631204#is_it_me_or_is_wiki_ver
y_slow.3F
As I browsed and edited the site today, I experienced similar issues
(painful slowness on intermittent page loads, loading half a page and then
stalling, etc.).
Is anyone from ops or engineering looking into this? I've filed a bug about
this as well: <https://bugzilla.wikimedia.org/show_bug.cgi?id=35448>.
It may be that this is a known issue (due to schema changes or whatever
else), but I don't think anyone from ops or engineering has commented on the
village pump (or elsewhere?). Can someone please take a look at what's going
on?
MZMcBride
Hi,
I posted a question at
https://www.mediawiki.org/wiki/Talk:Git/New_repositories , but i'm not
sure that that page is watched, so i'm poking here, too:
I couldn't find any guide for migrating an existing extension from SVN
to Git. The extension in question is TranslationNotifications, which
is not currently WMF-deployed, but probably will be soon. And the
question is relevant for all other extension.
Thank you.
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore