-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The Wikimedia foundation blog, is located at http://blog.wikimedia.org
Information about this blog can be located at
http://meta.wikimedia.org/wiki/Wikimedia_Blog
The blog is currently encouraging suggested post drafts from the
contributers on here at Wikimedia. Please check out the drafting
instructions at
http://meta.wikimedia.org/wiki/Wikimedia_Blog#Drafting_a_post
Send in your material!
An example of a post that could be drafted is the new SUL / Unified
login system. Perhaps a contributer knowledgeable in that area could
write something up. :)
Very Best!
Jon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIPpkP6+ro8Pm1AtURArnnAJ9fLIJMmbjW7XCw8lxrbenImv9SIwCbBlZJ
N+EU4+iVE9taBB2IX2tr8dI=
=1BDX
-----END PGP SIGNATURE-----
Hello,
I want to place block-level elements in the definition list, but it
is impossible. If I write
<dl><dt>term <dd><pre>
code here
code here</pre></dl>
I get (in ?action=render)
<dl><dt>term <dd><pre>
code here
code here</pre></dl>
which is not valid XML. If I write
<dl><dt>term</dt> <dd><pre>
code here
code here</pre></dd></dl>
I get
<dl><dt>term</dt> <dd><pre>
code here
code here</pre></dd></dl>
Placing <pre> (and other block-level elements) in ; term : definition
returns invalid XML too.
Wrote
;term : <pre>code1
code2
code3</pre>
and got
<dl><dt> term </dt><dd> <pre>code1
</dd></dl>
<p>code2
</p>
code3</pre>
I use mediawiki 1.12.0.
regards,
Khachik
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
someone on IRC asked me to forward this, something to do with writing about SUL
on the WMF blog...
- ----- Forwarded message from Jon <scream(a)datascreamer.com> -----
Date: Wed, 28 May 2008 21:00:36 -0500
From: Jon <scream(a)datascreamer.com>
To: Wikimedia Foundation Mailing List <foundation-l(a)lists.wikimedia.org>,
English Wikipedia <wikien-l(a)lists.wikimedia.org>
Subject: [Foundation-l] Wikimedia Foundation Blog
Reply-To: Wikimedia Foundation Mailing List <foundation-l(a)lists.wikimedia.org>
- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The Wikimedia foundation blog, is located at http://blog.wikimedia.org
Information about this blog can be located at
http://meta.wikimedia.org/wiki/Wikimedia_Blog
The blog is currently encouraging suggested post drafts from the
contributers on here at Wikimedia. Please check out the drafting
instructions at
http://meta.wikimedia.org/wiki/Wikimedia_Blog#Drafting_a_post
Send in your material!
An example of a post that could be drafted is the new SUL / Unified
login system. Perhaps a contributer knowledgeable in that area could
write something up. :)
Very Best!
Jon
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIPg5E6+ro8Pm1AtURAsG1AKChff/DbcmMDAzg9fNWIjkiqzskGQCgn3QV
C2WE9SD8rPPdWiCX6xisqPA=
=Ik3m
- -----END PGP SIGNATURE-----
_______________________________________________
foundation-l mailing list
foundation-l(a)lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
- ----- End forwarded message -----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (SunOS)
iEYEARECAAYFAkg+E4wACgkQIXd7fCuc5vIfigCfacrH30KkfUz4UVE3xnXQGbaN
gKAAn0i1vcL2DroJ5nIiFUbA/xAHrtJd
=j0IB
-----END PGP SIGNATURE-----
On Wed, May 28, 2008 at 8:22 AM, <werdna(a)svn.wikimedia.org> wrote:
> + // We expect at least one permissions error, because we're trying to do an action on a specialpage.
> + return count($this->getTitle()->getUserPermissionsErrors( 'centralauth-merge', $user ))<=1;
This is horrible. Why is it that we use a whitelist of allowed
actions for special pages instead of a blacklist?
On Wed, May 28, 2008 at 6:17 AM, <raymond(a)svn.wikimedia.org> wrote:
> Remove link to Special:Userrights for the moment as $wgUser->isAllowed( 'userrights' ) seems to strict in some cases
I think you want $userrights->userCanExecute( $wgUser ). In fact,
that's the generic way to check for permissions on special pages,
although in all other cases I know of it just falls back to
User::isAllowed.
The catch is that you'll have to instantiate a SpecialPage object,
although you won't actually be visiting the special page. It looks
like it should work, from reading the code, although you might want to
initialize UserrightsPage::$isself to true rather than false.
theoreticaly one should not be able to create an account that is a SUL
account on any wiki. But we have checked that you can create an account
with a name of an SUL account even if it is an fully integrated account.
Any solution?
masti
There's been some discussion at mediawiki-api about what we should do
with hooks in the API. There are currently three problems:
1. hooks that are supposed to be run aren't (such as ArticleDelete and
ArticleDeleteComplete before yesterday
2. some hooks that are run can mess up (such as AlternateEdit)
3. the 'hookaborted' error the API returns doesn't include details as to
who aborted the request and why
What I, personally, consider to be the best approach is to add new hooks
to the API modules, which provide a possibility for extensions to abort
the request and override the returned result. The only example thus far
is the APIEditBeforeSave hook (includes/api/ApiEditPage.php:132). Other
hooks should then be prevented from doing UI-specific things as much as
possible. The AlternateEdit hook, for instance, has no place in an API
request, as its very purpose is to override the edit form.
I've done an analysis of which hooks are run at which API request, and
whether I think they belong there. A report of my findings (basically a
list of hooks run at a certain request) can be found at the end of this
message.
Most initialization hooks (most notably the SpecialPage and LogPage*
hooks) are unnecessary for query requests (and also for many regular UI
requests). Shouldn't we lazy-load special page names and LogPage data?
The other lists look harmless, except for action=edit, which has the
AlternateEdit hook, which doesn't belong there. AlternateEdit serves to
replace the edit form. Extensions like AssertEdit that want to do
something for every action=edit request will have to use the right hooks
(APIEditPageBeforeSave or EditPage::attemptSave or whatever).
In general, I think most problems with action=edit are caused by the
fact that ApiEditPage currently just fools EditPage with a FauxRequest
object. There's a lot of mixture of UI and edit logic in EditPage, and I
think the best solution would be to split off the edit logic into a new
class. I'll be working on that in the ApiEdit_Vodafone branch for the
next few days, and I hope I can finish it before I go away for a week on
June 4th.
Roan Kattouw (Catrope)
Initialization hooks: (run for every API request, even action=query and
action=help)
- 'AuthPluginSetup' in Setup.php:258
- SpecialPage_initlist' in SpecialPage::initList()
- 'UserLoadFromSession' in User::loadFromSession()
- 'IsTrustedProxy' in wfIsTrustedProxy()
- 'LogPageValidTypes' in Setup.php:295
- 'LogPageLogName' in Setup.php:296
- 'LogPageLogHeader' in Setup.php:297
- 'LogPageActionText' in Setup.php:298
- 'UserEffectiveGroups' in User::getEffectiveGroups()
- 'UserGetRights' in User::getRights()
action=rollback runs the following hooks, in addition to the
initialization hooks and parser-related hooks I omitted for clarity:
- 'userCan' in Title::getUserPermissionsErrorInternal()
- 'getUserPermissionsErrors' in the same function
- 'getUserPermissionsErrorsExpensive' in the same function
- 'GetBlockedStatus' in User::getBlockedStatus()
- 'PingLimiter' in User::pingLimiter()
- 'ArticleSave' in Article::doEdit()
- 'ArticlePageDataBefore' in Article::pageData()
- 'ArticlePageDataAfter' in the same function
- 'ArticleAfterFetchContent' in Article::fetchContent()
- 'RevisionInsertComplete' in Revision::insertOn()
- 'NewRevisionFromEditComplete' in Article::doEdit()
- 'UserArrayFromResult' in UserArray::newFromResult()
- 'RecentChange_save' in RecentChange::save()
- 'ArticleEditUpdatesDeleteFromRecentchanges' in Article::editUpdates()
- 'SearchUpdate' in SearchUpdate::doUpdate()
- 'ArticleSaveComplete' in Article::doEdit()
- 'ArticleRollbackComplete' in Article::commitRollback()
action=delete:
- 'userCan' in Title::getUserPermissionsErrorInternal()
- 'getUserPermissionsErrors' in the same function
- 'getUserPermissionsErrorsExpensive' in the same function
- 'GetBlockedStatus' in User::getBlockedStatus()
- 'ArticleDelete' in ApiDelete::delete()
- 'ArticlePageDataBefore' in Article::pageData()
- 'ArticlePageDataAfter' in the same function
- 'ArticleAfterFetchContent' in Article::fetchContent()
- 'UserArrayFromResult' in UserArray::newFromResult()
- 'RecentChange_save' in RecentChange::save()
- 'ArticleDeleteComplete' in ApiDelete::delete()
action=undelete:
- 'GetBlockedStatus' in User::getBlockedStatus()
- 'RevisionInsertComplete' in Revision::insertOn() (for every restored
revision)
- 'ArticleRevisionUndeleted' in PageArchive::undeleteRevisions() (for
every restored revision)
- 'userCan' in Title::getUserPermissionsErrorsInternal()
- 'getUserPermissionsErrors' in Title::getUserPermissionsErrorsInternal()
- 'ArticlePageDataBefore' in Article::pageData()
- 'ArticlePageDataAfter' in the same function
- 'ArticleAfterFetchContent' in Article::fetchContent()
- 'ArticleEditUpdatesDeleteFromRecentchanges' in Article::editUpdates()
- 'ArticleUndelete' in PageArchive::undeleteRevisions()
- 'UserArrayFromResult' in UserArray::newFromResult()
- 'RecentChange_save' in RecentChange::save()
- 'SearchUpdate' in SearchUpdate::doUpdate()
action=protect:
- 'GetBlockedStatus' in User::getBlockedStatus()
- 'userCan' in Title::getUserPermissionsErrorInternal()
- 'getUserPermissionsErrors' in the same function
- 'getUserPermissionsErrorsExpensive' in the same function
- 'ArticleProtect' in Article::updateRestrictions()
- 'RevisionInsertComplete' in Revision::insertOn()
- 'NewRevisionFromEditComplete' in Article::updateRestrictions()
- 'ArticleProtectComplete' in Article::updateRestrictions()
- 'UserArrayFromResult' in UserArray::newFromResult()
- 'RecentChange_save' in RecentChange::save()
action=block:
- 'BlockIp' in IPBlockForm::doBlock()
- 'BlockIpComplete' in IPBlockForm::doBlock()
- 'UserArrayFromResult' in UserArray::newFromResult()
- 'RecentChange_save' in RecentChange::save()
action=unblock:
- 'UserArrayFromResult' in UserArray::newFromResult
- 'RecentChange_save' in RecentChange->save
action=move:
- 'userCan' in Title->getUserPermissionsErrorsInternal
- 'getUserPermissionsErrors' in Title->getUserPermissionsErrorsInternal
- 'getUserPermissionsErrorsExpensive' in
Title->getUserPermissionsErrorsInternal
- 'GetBlockedStatus' in User->getBlockedStatus
- 'AbortMove' in Title->isValidMoveOperation
- 'RevisionInsertComplete' in Revision->insertOn (twice)
- 'NewRevisionFromEditComplete' in Title->moveToNewTitle (twice)
- 'UserArrayFromResult' in UserArray::newFromResult
- 'RecentChange_save' in RecentChange->save
- 'SearchUpdate' in SearchUpdate->doUpdate
- 'TitleMoveComplete' in Title->moveTo
Note: this used to run AbortMove twice, once in ApiMove::execute()
(where it doesn't belong) and once in Title::isValidMoveOperation()
(where it does belong)
action=edit:
- 'userCan' in Title::getUserPermissionsErrorsInternal()
- 'getUserPermissionsErrors' in Title::>getUserPermissionsErrorsInternal()
- 'getUserPermissionsErrorsExpensive' in
Title::getUserPermissionsErrorsInternal()
- 'GetBlockedStatus' in User::getBlockedStatus()
- 'AlternateEdit' in ApiEditPage::execute()
- 'APIEditBeforeSave' in ApiEditPage::execute()
- 'EditPage::attemptSave' in EditPage::internalAttemptSave()
- 'EditFilter' in EditPage::internalAttemptSave()
- 'PingLimiter' in User::pingLimiter()
- 'ArticlePageDataBefore' in Article::pageData()
- 'ArticlePageDataAfter' in Article::pageData()
- 'ArticleAfterFetchContent' in Article::fetchContent()
- 'EditFilterMerged' in EditPage::internalAttemptSave()
- 'ArticleSave' in Article::doEdit()
- 'RevisionInsertComplete' in Revision::insertOn()
- 'NewRevisionFromEditComplete' in Article::doEdit()
- 'UserArrayFromResult' in UserArray::newFromResult()
- 'RecentChange_save' in RecentChange::save()
- 'ArticleEditUpdatesDeleteFromRecentchanges' in Article::editUpdates()
- 'ArticleSaveComplete' in Article::doEdit()
- 'ArticleUpdateBeforeRedirect' in Article::updateArticle()
- 'GetLocalURL' in Title::getLocalURL()
- 'GetFullURL' in Title::getFullURL()
- 'SearchUpdate' in SearchUpdate::doUpdate()
brion(a)svn.wikimedia.org schreef:
> Revision: 35445
> Author: brion
> Date: 2008-05-27 22:36:33 +0000 (Tue, 27 May 2008)
>
> Log Message:
> -----------
> Revert r35442 -- appears to try to add the centralauth GLOBAL tables to EVERY LOCAL database when you run update.php
Oh right, they're supposed to be in a separate database... that kind of
went past me.
Roan Kattouw (Catrope)
Here's the report:
https://bugzilla.wikimedia.org/show_bug.cgi?id=14273
I'm happy to apply the patch assuming the SVN commit access I've never used
still works.
I'm just about done porting the RDF extension to the Redland libraries, so
I'll have more to submit shortly.
thanks,
-mark
--
--
=================================================================
-- mark at geekhive dot net --
Hi,
I am referring to the dump at: http://download.wikimedia.org/zhwiki/20080425/
I can only find the categorylinks.sql.gz (only single level), but not
the full category
table which contains all the categories.
Any data I have missed?
Thanks.
Howard