Brion Vibber <brion <at> wikimedia.org> writes:
> $wgUploadUrl is set incorrectly on this site to "images" instead of
> "/ProjectWiki/images".
>
> This reliative URL is resolved by the browser from /ProjectWiki/index.php
> ok, but not by anything else -- your code snippet simply adds a "/" on
> the front, making it "/images". (Note this will also fail if
> $wgUploadUrl is a fully-qualified URL, such as on sites which serve
> their images from a separate domain.)
>
I think you mean $wgUploadPath instead of $wgUploadUrl.
I found nothing about $wgUploadUrl at
http://www.mediawiki.org/wiki/Category:Upload_variables
Adding the starting slash if not existent was only a quick and dirty
workaround, because at first the problem seemed to be a missing slash
in the middle of the URL. Maybe no good idea.
The Wiki sysop told me he had to set $wgUploadPath="/images" (or "images"?)
to get another extension to work. I thought this would cause no problems:
Uploads go to the new directory http://robertfant.com/images (or better,
one of its subdirectories) and files are retrieved by getURL() from the
same place. Seems not to be true. New uploads still go to
http://robertfant.com/ProjectWiki/images/<subdir>/subdir>/... Why?
Just for sake of clarity:
What is the difference between $wgUploadPath="/images" and
$wgUploadPath="images"?
What will the Wiki sysop have to do that uploaded files go to the same place
where my extension will retrieve them?
Does it help to change both $wgUploadPath and $wgUploadDirectory?
How did you know so quickly about the content of $wgUploadPath without
access
to LocalSettings.php? Maybe there is a Special:XYZ page showing the content
of all $wgXYZ variables.
--Rudi
http://www.formelapplet.de
(replying to foundation-l post on wikitech-l)
On Mon, Apr 27, 2009 at 12:45 PM, Brion Vibber <brion(a)wikimedia.org> wrote:
> So far this is the best way to provide a dynamic notice to the majority
> of our visitors without causing problems for others. If you have
> technical suggestions for alternate implementations, they're welcome in
> a more relevant channel such as wikitech-l.
The only non-script solution that seems like it would work well is
<iframe seamless> from HTML5:
http://www.w3.org/TR/html5/embedded-content-0.html#attr-iframe-seamless
This solves the current problem that <iframe>s must have a
prespecified height, which is why we can't use them now. Of course,
<iframe> isn't necessarily terribly well supported in weird browsers,
but it would be better than JavaScript.
One possible way we might have more graceful fallback now is to have
some <noscript> content. One possibility would be an <iframe>
containing the content (which might be the wrong height, but oh well);
another would be to have a message pointing to the announcements. Of
course, it would be non-dismissible without JavaScript, so it would be
best to keep it less obtrusive if possible. So the message seems like
a better idea.
Hi,
In the date delinking proposed decision I have added four principles
that relate to the technical community. They are a draft only. If
there any major objections here or on the talk page, I will drop them
over on the Workshop page so discussion can occur there.
http://en.wikipedia.org/wiki/Wikipedia:Requests_for_arbitration/Date_delink…
===MediaWiki developers===
18) The projects run by the Wikimedia Foundation, such as the English
Wikipedia project, are run on the MediaWiki software, which is an open
source project hosted by the Wikimedia Foundation.
As it is an open source project, anyone may participate in the
improvement of the software, by way of patches, however these changes
are subject to approval by the core MediaWiki development team.
The MediaWiki development team are part of the Wikimedia community,
however their development work is beyond the jurisdiction of the
English Wikipedia community and its Arbitration Committee. The paid
development team is answerable to the Foundation, and the Board
influences the development priorities based on the needs of the
projects, of which English Wikipedia is only one of many. The
Wikimedia projects may, of course, question their decisions but must
at all times respect those decisions. Bug reports, feature requests,
complaints and concerns should be lodged at the appropriate forums,
such as Bugzilla, mediawiki.org, mediawiki-l and wikitech-l, and
foundation-l or meta for larger problems, with each of these forums
having their own processes and customs which should be respected.
===System administrators===
19) System administrators are responsible for the MediaWiki software
configuration of the projects run by the Wikimedia Foundation, such as
English Wikipedia. They make changes to configuration based on a mix
of Wikimedia Foundation, technical and project considerations. While
their decisions may affect the English Wikipedia, those decisions are
beyond the jurisdiction of the English Wikipedia community and its
Arbitration Committee. The local community may, of course, challenge
these decisions, but must at all times respect them, Complains should
be lodged at meta forums, such as Bugzilla, #wikimedia-tech,
wikitech-l, foundation-l and meta, each having their own processes and
customs which should be respected.
===Open source===
20) The software used by the English Wikipedia project is open source
and may be improved by anyone, by way of bug reports, design
documents, code patches, technical documentation, etc. Fair criticism
of open source software is acceptable, however it is incumbent on
everyone to participate in [[wikt:build a better mousetrap|building a
better mousetrap]]. Deriding the developers who are in short supply
is not acceptable. Developers are volunteers, and at no time is it
acceptable to expect them to fix non-critical problems.
===Deprecation of MediaWiki functionality===
21) The MediaWiki software used on the Wikimedia projects, and
configuration of that software, is the responsibility of the
developers and system administrators.
In the same way that system administrators are the decision makers to
enable new functionality, deprecation or removal of MediaWiki
functionality is a technical decision, and implementation of that
decision may have technical implications that need to be considered.
The project community should engage the technical team in decisions
which relate to use the software.
Policies, procedures and the manual of style may govern how and when
the software may be used, however decisions to deprecate or disable
software features are best left in the hands of the technical staff.
Regards,
John Vandenberg
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello all!
I have been writing an extension
http://www.mediawiki.org/wiki/Extension:DynamicTabs that works just
fine in my test-wiki. Now I have tried to install it on another wiki
and the whole thing crash when I try to create the config page on
wiki, called Mediawiki:DynamicTabs:
*Fatal error*: Call to undefined method Article::getRawText() in
*/var/www/mickenordin/mediawiki/extensions/DynamicTabs/DynamicTabs.php*
on line *85
*
This is the relevant part of the code:
$DynTabsPage =
Article::newFromId(Title::newFromText("Mediawiki:DynamicTabs")->getArticleId());
if(isset($DynTabsPage))
{
$DynTabsText = explode("*", $DynTabsPage->getRawText()); //Line 85*
* *a bunch of other stuff here*
I can't figure out what is wrong, so I thought I'd shoot you all an
email to see if any one has some insight to share. The rest of the
code of the extension can be found here:
http://micke.googlecode.com/files/DynamicTabs-0.2.tar.gz
Since Article::getRawText() clearly isn't undefined I must be doing
something else wrong... Also it seems strange that the code works in
one wiki, but not another set up on the same server.
/Micke
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkn5zUMACgkQzdNqVVhZvLw5VACdGzS/rAbSQgSYSag+dBXXJA+n
XosAniKhbb15tUIMaDBMUzcazeCgEr8+
=5FUW
-----END PGP SIGNATURE-----
I've created a branch for the eventual release of MediaWiki 1.15,
based on r48811. Some bugfixes will need to be backported, we're
keeping track of them at bug #18629.
If you feel a need to commit directly to the 1.15 branch instead of
adding a note to the bug report, can you please explain in your commit
message why you think the change is important enough to require
immediate release? In previous releases, figuring out why people were
backporting things was a large part of the release workload.
-- Tim Starling
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Special:Version displays SVN version numbers for extensions out of
$wgExtensionCredits, which seems to be done with $LastChangedRevision$
keywords in the extension's entry point file.
This produces massively incorrect numbers in many cases, since the entry
point file is relatively rarely changed in non-trivial extensions
consisting of multiple files. Updates to the body, class, i18n, and
other files are not reflected.
If we're running on a SVN checkout of the extension, we could check the
directory for its current revision much as we do for MediaWiki itself;
this would tell us for instance if an extension's subdirectory has been
updated separately from the core MediaWiki.
But if we aren't on a SVN checkout, or if individual files have been
updated to different versions, this may or may not tell us anything useful.
Anybody have a suggestion on how to best handle this?
- -- brion
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAklb6VcACgkQwRnhpk1wk44MNACg2c0ztpocjHfsb5l+KxSu8e+I
wXgAoMSrjFeTPzEnMY4904bxXZv+DiYf
=GNqG
-----END PGP SIGNATURE-----
Hi
Are there any plans to make Wikipedia a opneID provider? I would really be
interesting if we could log on to wikipedia-replated sites with the same ID.
Thanks,
Andrei Cipu
Hi all,
Just a quick note to let everybody know that in a few days I'll be
changing the TorBlock configuration to require explicit block
exemption rather than merely being logged in.
While we would rather this weren't necessary, it seems that the edits
coming through tor are mostly unconstructive; and we've had all kinds
of nasty harassment come through that way -- the community feedback we
asked for was overwhelmingly that the ideological benefits of allowing
truly anonymous editing are outweighed by the pragmatic concerns of
harassment and vandalism.
To facilitate this, I will also be activating explicit IP block
exemption on all wikis. Like on English Wikipedia and many other
wikis, administrators will be able to add users to an "IP block
exempt" group, which exempts its holder from IP blocks, range blocks
and autoblocks, *but not explicit user blocks*. This is a helpful,
albeit inaccessible way to defray some of the problems associated with
blocking Tor users carte blanche.
Please let me know if you have any questions, comments, concerns or
suggestions about these changes!
--
Andrew Garrett
I just got:
This wiki has a problem
Sorry! This site is experiencing technical difficulties.
Try waiting a few minutes and reloading.
(Cannot contact the database server: No working slave server: Unknown
error (10.0.2.185))
What's missing? A donation beg notice! Downtime being, of course, our
most profitable product ...
(I also recall there being a multilingual error page. Is this one
en:wp-specific?)
- d.