Hi,
I am specifying:
$wgDefaultRobotPolicy = 'index,follow';
$wgNamespaceRobotPolicies = array( NS_MAIN => 'index,follow' );
$wgArticleRobotPolicies = array( 'Main Page' => 'index,follow' );
in my LocalSettings.php file but it is not generating any "robot.txt" file.
Mediawiki is supposed to generate this file right?
Thanks,
Hi Brion,
I wrote recently on this mailing list, that I'm going to accommodate one of my extensions called "News Channel" (http://www.mediawiki.org/wiki/Extension:News_Channel) for installation on Wikinews project to produce full-featured RSS/Atom feeds there.
There are some issues, I forgot, that Wikimedia servers use MySQL 4.0, that doesn't support subqueries, so I'll have to redesign complex SQL queries. But I'm going to correct this and other minor issues soon, and finish accomodation. For now, I ask you to grant me commit access on Wikimedia subversion system, please, so I could store my source codes there and collaborate with other developers more efficiently.
With best regards,
Iaroslav Vassiliev
On Wed, Jul 9, 2008 at 5:11 PM, <vasilievvv(a)svn.wikimedia.org> wrote:
> Log Message:
> -----------
> * Forbid files with * and ? to be uploaded under Windows (it caused internal errors since such characters are illegal there)
It seems like it would be a better idea to be consistent across
platforms here. Otherwise you're just going to cause trouble for
portability; for instance, Windows users would be unable to easily use
an image dump from Wikimedia, or other Unix-based MediaWiki
installations.
However, we don't *really* have to use the same name in the filesystem
as we use as a title. This seems to me like it would be better
implemented by mangling the filename somehow. The invalid Windows/DOS
characters are supposedly:
? [ ] / \ = + < > : ; " ,
Of those, I think the following are currently legal in image names
(before your commit):
? \ = + : ; " ,
Each of these could be replaced in the filesystem by some character
that Windows will accept, or some combination of them, which are
invalid image names anyway. For instance, you could replace them with
{question} {backslash} {equals} {plus} {colon} {semicolon} {quote}
{comma}; these will work correctly because {} are illegal in page
titles but legal in Windows filenames. (But they could send filenames
over the file length limit, so more creative substitutes might be a
better idea.) This way the rules for image titles remain unchanged,
which is nice because a lot of those characters are quite handy to
have in titles.
(Googled sources actually conflict as to the exact list of prohibited
characters. Some say * is prohibited, some don't mention it. Same
for |. ^ is apparently supposed to be illegal in FAT, according to
one source, and there are other restrictions, like no trailing space
or period, and a list of reserved names like "com1" and "nul".
Probably it varies across different versions, but it's a lot bigger
than just ? and *, anyway.)
> * Forbid files to be moved to invalid filenames
This might be more cleanly implemented by making invalid filenames
invalid titles in the Image namespace. That would make things
somewhat simpler by keeping things in more expected places. It also
makes sense to prohibit image pages from existing when it's not
possible for an image of that title to exist. (But projects will need
to be checked for pages that will become invalid under this scheme, of
course, perhaps using a maintenance script.)
> +/**
> + * Checks filename for validity
> + * @param mixed $title Filename or title to check
> + */
> +function wfIsValidFileName( $name ) {
Surely this shouldn't be a global function, but a static method of
something? Or even a non-static method of something.
> + elseif( wfIsWindows() && ( in_string( '*', $name ) || in_string( '?', $name ) ) )
> + return false;
> . . .
> + if( wfIsWindows() )
> + $filtered = preg_replace ( "/[*?]/", '-', $filtered );
Magic constants here. You have a list of blacklisted characters
scattered across multiple files, that's bad. They could become
inconsistent over time.
wow, thankyou so much for this! But this new feature unfortunately
overridethe js used as a workaround to bug:708... (the bug:708 is on
the ToDo list
from someone? )
On Mon, Jul 7, 2008 at 10:19 PM, Tim Starling <tstarling(a)wikimedia.org>
wrote:
> It's now possible to move the search box up in the sidebar, above links
> generated by [[MediaWiki:Sidebar]]. This is done by adding a section
> called "SEARCH" (case-sensitive) to [[MediaWiki:Sidebar]], in the location
> you think it should be. For instance:
>
> * SEARCH
> * navigation
> ** mainpage|mainpage
> ** Portal:Contents|Contents
> ** Portal:Featured content|featuredcontent
> ** currentevents-url|currentevents
> ** randompage-url|randompage
>
> It's also possible to move the languages box and the toolbox in the same
> way, using LANGUAGES and TOOLBOX.
>
> Do not put second-level links under the special headings:
>
> * SEARCH
> ** Don't add a line like this
>
> It doesn't do anything useful (yet).
>
> -- Tim Starling
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
Hi Brion,
Since we have more than one developer working on developing PMWX extension.
We will prefer if multiple people can have rights to use the SVN account *
pmwx.
*Can we send public keys to be added to this account.
Appreciate your help.
Thanks
*--Viral
*
On 4/11/08, Brion Vibber <brion(a)wikimedia.org> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Added:
>
> mfarag (Meno25) - Arabic localization updates
>
> pmwx (Viral Gupta) - Purple Numbers extension
>
> multichill (Maarten Dammers) - Pywikipediabot stuff
>
> dantman (Daniel Friesen) - Title casing alternate branch
>
> nicdumz (Nicolas Dumazet) - Pywikipediabot stuff
>
> - -- brion vibber (brion @ wikimedia.org)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkf/5SAACgkQwRnhpk1wk46OLACeOqs8fjG+WDHz5HpPtbTSOrFT
> 3ZsAoMFChZYKsEp+rg416924DYZG3YHr
> =mSe+
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
On Fri, Jul 11, 2008 at 4:57 AM, <siebrand(a)svn.wikimedia.org> wrote:
> Log Message:
> -----------
> Use a .org RFC2606 compliant example URL
> . . .
> -'extlink_sample' => 'http://www.example.com link title',
> +'extlink_sample' => 'http://www.example.org link title',
Is this meant to imply that example.com is not an RFC 2606-compliant
example URL? Because it is. RFC 2606 reserves the three domain names
example.com, example.net, and example.org, as well as the four
top-level domain names .test, .example, .invalid, and .localhost.
Scenario: Logged in to en.wp via secure server, just blocked an IP address.
The successful blocked page returns unsecure URLs
(http://en.wikipedia.org/wiki/...) for several of the user info
subpages for the just-blocked user.
The list reads: (talk * edit talk * message * contribs * block log *
unblock * watch)
Of those, edit talk, message, block log, unblock, and watch all go to
the unsecure en.wp URL. Only talk and contribs go to secure URLs.
I have not had time to look into the code and see what's going on.
--
-george william herbert
george.herbert(a)gmail.com
Hi,
i have mediawiki last version, installed on a Linux Red Hat box, but
when i try to access the wiki interface this is too slow. How can i do
to fix this?
Thanks.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
aaron(a)svn.wikimedia.org wrote:
> Add form accesskey (bug 14783)
> $form .= Xml::submitButton( wfMsgHtml('revreview-submit'),
> - array('id' => 'mw-submitbutton','class' => 'fr-comment-box')+$toggle);
> + array('id' => 'mw-submitbutton','class' => 'fr-comment-box','accesskey' => 's')+$toggle );
Where possible, avoid hardcoding accesskeys this way. Within the core
software we make them localizable, so they can be changed via MediaWiki:
messages, and pair them with tooltip messages.
You can fetch the appropriate accesskey and tooltip title attribute via
$skin->tooltipAndAccesskey('whatever').
Note though that this function is currently dreadful, returning raw HTML
fragments. I half-did some improvements on a patch to bug 14757 for
cleaning this up, which it would be great if some enterprising lad
finished resolving:
https://bugzilla.wikimedia.org/show_bug.cgi?id=14757
- -- brion
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkh2gm4ACgkQwRnhpk1wk44WOQCdGl0iLZn8W7n3urwKEICUOsBY
eRYAoL8I8EZD2SBC9Pa3uE9Rt+INpzzD
=uOZV
-----END PGP SIGNATURE-----