As I understand it, the MediaWiki system works by interpreting the
"source code" as stored in the database and rendering it into HTML. I
am curious to know how tightly connected the code is to the database.
My ultimate goal is to make a WYSIWYG "offline" wiki editor. The user
would browse the wiki as normal, but on pressing the Edit link (or a
command in the app itself), it would download the source to a local
cache for editing. I do this many times with my text editor, but I
would like something much more capable, looking for missing closing
refs and brackets, offering a separate window to keep cites and other
clippings that are auto-included at the end, and offering a realtime
preview
In order for this to work the interpreter would have to be able to be
fed from a text file, or even better, a buffer. I would use CURL to
manage downloading the storing the source, WebKit to display the
rendered results, and various Cocoa objects to wrap it all together.
Any comments from the techs out there? Is this doable?
Maury
Anyway of keeping these from wasting bandwidth,
GET /index.php?title=Special:Search&ns0=1&redirs=0&searchx=1&search=487.3000 "Baiduspider
GET /index.php?title=Category:130.6000&action=edit Googlebot/2.1
_without_ worrying about making pretty URLs (so one can use "index.php" in
robots.txt)?
Why can't there be a nofollow added to such links next version?
http://upload.wikimedia.org/wikipedia/commons/thumb/c/c8/Kodak-Vollenda620-…
gives
Error generating thumbnail
Error creating thumbnail:
/usr/local/apache/common/php-1.5/bin/ulimit4.sh: line 4:
/usr/bin/convert: No such file or directory
On the next try:
Error generating thumbnail
Error creating thumbnail: convert: Insufficient memory (case 4)
`/mnt/upload3/wikipedia/commons/c/c8/Kodak-Vollenda620-detail.jpg'.
convert: missing an image filename
`/mnt/upload3/wikipedia/commons/thumb/c/c8/Kodak-Vollenda620-detail.jpg/166px-Kodak-Vollenda620-detail.jpg'.
Note that this is the Commons picture of the day, so a failure to
generate a decent-sized thumbnail from it is rather serious from a
user perspective, IMHO.
Magnus
Hi,
at the moment I#ve quite some problems. I'm working to implement a
wizard class which leads users through the first steps on writing new
articles. There fore I'want to redirect the url under the conditions of
a new article to something like ?title={title}&action=new
####################### CORE ###########################################
# Register hooks
$wgHooks['ArticleFromTitle'][]='wizardBaseInterface';
function wizardBaseInterface($title, $article)
{
/* If the article already exists, make sure to forward to
* editpage->view
* otherwise start wizard
*/
if ($title->exists())
{
return true;
}
global $wgHooks;
if (($title->mArticleID != '0') && $article->exists())
$wgHooks['AlternateEdit'][]='wbiSkipToArticleView';
else
$wgHooks['AlternateEdit'][]='wbiSkipToNewArticleWizard';
/* Give other extensions a chance to run */
return true;
}
/**
* Forwards to Article->view() - meant to be attached to 'AlternateEdit'
dynamically.
* @param EditPage $editPage An instance of EditPage whose mArticle will
be viewed.
*/
function wbiSkipToArticleView($editPage)
{
$editPage->mArticle->view();
return false;
}
/**
* Forwards to WizardBase - meant to be attached to 'AlternateEdit'
dynamically.
*/
function wbiSkipToNewArticleWizard()
{
global $title;
$newPageWizard=new newPageWizard($title);
return false;
}
##################################################################################
Thanks for some advices
mic
Hello,
I'd like to throw in my idea to get some suggestions.
Because I've been contacted couple times by different wiki admins as well as WMF-wikis' users about that, I thought it would be good idea to incorporate it in MediaWiki.
The idea is to create another default group of users with working title "poweruser" since the step between normal user and sysop is too high. The most often request was to have poweruser to be able to edit protected pages without being able to change the level of the protection.
Therefore I filed bug 10897 to get the necessary prerequisites. Later on I've been explained on #mediawiki there might be problems with backward compatibility, so I've reformulated it in bug 10974.
However, during the talk on #mediawiki about technical stuff about "editprotected" right the opinion it's not necessary to have another default group ("poweruser") popped up. That's why I decided to throw it in to see more opinions about that.
Now some cases why I think it would be reasonable to have it as default:
* Having poweruser able to edit protected pages could mean that user gained higher level of reliability or trust. So if the wiki has say half of articles protected (one admin told me he set his wiki to subjects are protected, their talkpages are open), currently there would have to be a bunch of sysops to be able to edit it which is unwanted.
* There's no cascade semi-protection at the moment available, so eg. if Main Page is protected with cascade, normal users can't simply edit its parts such as article/image of the week, did you know..., actualities etc. Sysops have to take care about which is not flexible. Those parts are most usually edited by same people, so these could be the members of the poweruser group.
Summary:
My idea is to add new default group "poweruser" (or choose any other name) with default rights same to normal user plus the new "editprotected" right by default since it's the most requested. Each wiki could add more rights on demand then.
Thanks in advance for any suggestions.
Kind regards
Danny B.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello!
You are receiving this email because your project has been selected
to take part in a new effort by the PHP QA Team to make sure that
your project still works with PHP versions to-be-released. With this
we hope to make sure that you are either aware of things that might
break, or to make sure we don't introduce any strange regressions.
With this effort we hope to build a better relationship between the
PHP Team and the major projects.
If you do not want to receive these heads-up emails, please reply to
me personally and I will remove you from the list; but, we hope that
you want to actively help us making PHP a better and more stable tool.
The second release candidate of PHP 5.2.4 was just released and can
be downloaded from http://downloads.php.net/ilia/. This RC includes
only bug fixes, about 20 of them, the bulk of the effort has been
towards improving the stability. Thus far the feedback from testers
has been good, so if all goes well they may very well be the final
RC. Please try this RC against your code base and let us know if you
discover any problems.
In case you think that other projects should also receive this kinds
of emails, please let me know privately, and I will add them to the
list of projects to contact.
Best Regards,
Ilia Alshanetsky
5.2 Release Master
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)
iD8DBQFGxPcxLKekh381/CERAoGyAJ9W1iOYAyKVDdYfl6w0jn5lxhZJrQCfWjpv
iGZiGg4pXIvCqbaX+p7N0mM=
=xofU
-----END PGP SIGNATURE-----
For those involved in the recent Picnik discussion, you might find
this interesting:
http://wikicanvas.com/
Java-based in-page SVG editing. Anons can edit. :)
Their wiki doesn't have a diff or a revert function yet which is a bit
of a worry since I just deleted one of the images by removing all its
components :o
cheers
Brianna
--
They've just been waiting in a mountain for the right moment:
http://modernthings.org/
Hi everybody,
I just had a bit of a flashbulb going off a few days ago
and I thought I'd share it with you.
I work in the Visual Effects industry and we constantly
have to compare almost identical versions of the same
image. The way we do this, beside a standard side-by-side
comparison, is to quickly (but manually) switch from one
image to the other, back and forth, so that our eyes can
easily pick up the differences (*).
I thought this could be useful to extend the wiki way
of doing things to images, especially SVGs. The history
interface would remain the same but the browser would
put the two images on two different layers, one obscuring
the other, and a simple button would allow (ideally through
javascript) to swap the two quickly. Of course a standard
diff would then be available to inspect the differences in the
actual code if the image in question is SVG.
What do you think?
Ciao!
Manu
(*) human eyes are excellent at picking up changing details
in an unchanging scene. Interestingly, they are also very
good at picking up still details in a rapidly changing scene.
This is probably due to the first case representing a prey
or a predator in an otherwise unchanging landscape, and
the latter case representing a static prey or predator in
a view with lots of moving features, i.e. leaves and branches.
