I have this weird thing with wiki syntax: Consider a template with
"optional columns", like so:
{|
! Foo
{{#if: {{{bar|}}} | ! Bar}}
{{#if: {{{baz|}}} | ! Baz}}
|-
| {{{foo}}}
{{#if: {{{bar|}}} | {{!}} {{{bar}}}}}
{{#if: {{{baz|}}} | {{!}} {{{baz}}}}}
|}
Now, if I transclude that template and leave out {{{bar}}} and
{{{baz}}}, I get this markup:
<table>
<tr>
<th> Foo
<p><br />
</p>
</th></tr>
<tr>
<td> {{{foo}}}
<p><br />
</p>
</td></tr></table>
This is clearly, then, caused by the newline between the canditional
bar and conditional baz lines resolving to empty strings, making the
foo cells in each row have paragraphs containing line breaks. So how
do I get rid of it without, say, putting both rows into one compact row?
Hello,
I'm trying to setting up the option to upload files on the wiki.
I've set the uploading to true in the localsettings.php file, and set
the extensions I want to allow.
$wgEnableUploads = true;
$wgFileExtensions = array( 'png', 'gif', 'jpg', 'jpeg', 'pdf', 'txt' );
Then I've uncommented the part for the safemode on :
$wgHashedUploadDirectory = true;
I've made the 3 directories images/archive, images/thumb and
images/temp, which are all writeable (chmod 777).
When trying to upload a file (simple jpg), I get an error : "Unable to
rename the file « /public_html/upload/tmp/phpY5H1qn » to
« public/5/5d/Panneau_004.jpg ». "
The path is not the same. I don't know where the second path comes from.
In my /public_html/images folder, there is a folder "5" created, with
chmod 755, and I can't seem to modify the authorisations, they stay the
same.
What do I do wrong?
On that note, is there really any better way we could
do this? Right now if I'm remember correctly we check
the results of an EXPLAIN for an estimate. Is select
count(*) just impossibly slow, even if we cached the
result for an hour or whatever?
-Chad
On Sep 20, 2009 10:49 PM, "Tim Starling" <tstarling(a)wikimedia.org> wrote:
APseudoUtopia wrote: > I'm running MW 1.15.1. I'm having a problem with the
Job Queue. I > noticed t...
This is most likely due to a known bug in Special:Statistics, which
causes it to give inaccurate numbers for the number of jobs remaining
in the queue. You can get an accurate count by running an SQL query,
say using phpMyAdmin:
SELECT COUNT(*) FROM jobs;
-- Tim Starling
_______________________________________________ MediaWiki-l mailing list
MediaWiki-l(a)lists.wikimed...
I'm currently trialling the SecurePages extension (formerly httpsLogin)
to force a https connection for Special:Userlogin and then redirect to
http for normal usage of the wiki. By default the extension sets
$wgCookieSecure to false since MediaWiki obviously can't read cookies
set with the secure flag when not using an encrypted connection.
I'm curious whether anyone has any input on the security implications of
using $wgDisableCookieCheck instead of disabling $wgCookieSecure.
Thanks,
Tim.
I'm running MW 1.15.1. I'm having a problem with the Job Queue. I
noticed that on Special:Statistics, the job queue length is always
1,200. Ever since I started the wiki, it has been the same thing -
1,200 - the entire time. The wiki does have a light load, so I tried
setting $wgJobRunRate to a higher number such as 5, then browsing the
site a bit and monitoring the JobQueue length. Nothing changed.
How can I get more information on this? Such as, what jobs are
actually in the queue? Why aren't they running?
Thanks.
I have taken a look at this extension:
http://www.mediawiki.org/wiki/Extension:MassUserImport
> Though I would need to give usernames other than the
> first part of the email, as it is done.
I do not understand what you mean. Please give me an example with
three users, thanks!
Regards,
Claus
Hi,
We've written a script that imports data from a non-wiki source into our
wiki by transforming it to XML import files, and importing it with the
importdump.php maintenance script. This all works very well, except that
we would like to protect the imported pages. As specified in the help
pages, I've included a line
<restrictions>edit=sysop:move=sysop</restrictions> in the page element.
Unfortunately, this doesn't work (I've tried other values as well).
Is this just reserved syntax for a planned feature, or should it
actually work? I've noticed that something does happen for the
restrictions element in the php code, but I can't work out what. If it
should work, can anyone tell me what the syntax is supposed to be?
many thank,
Peter
@Peter: Please do not make fullquotes, thanks!
Why? http://www.netmeister.org/news/learn2quote2.html#ss2.5
> Do you have any idea
> of how sensitive this might be to future upgrades and changes in the
> database model?
Being not "in the team" (developement), I have absolutly no clue.
> Does the page_restrictions table structure tend to
> change very much?
IMHO they do not change often.
============================
Version 1.11.0:
CREATE TABLE mw_page_restrictions (
pr_page int(11) NOT NULL,
pr_type varbinary(60) NOT NULL,
pr_level varbinary(60) NOT NULL,
pr_cascade tinyint(4) NOT NULL,
pr_user int(11) default NULL,
pr_expiry varbinary(14) default NULL,
pr_id int(10) unsigned NOT NULL auto_increment,
PRIMARY KEY (pr_page,pr_type),
UNIQUE KEY pr_id (pr_id),
KEY pr_typelevel (pr_type,pr_level),
KEY pr_level (pr_level),
KEY pr_cascade (pr_cascade)
) TYPE=MyISAM;
Version 1.13.3:
CREATE TABLE www_page_restrictions (
pr_page int(11) NOT NULL,
pr_type varbinary(60) NOT NULL,
pr_level varbinary(60) NOT NULL,
pr_cascade tinyint(4) NOT NULL,
pr_user int(11) default NULL,
pr_expiry varbinary(14) default NULL,
pr_id int(10) unsigned NOT NULL auto_increment,
PRIMARY KEY (pr_page,pr_type),
UNIQUE KEY pr_id (pr_id),
KEY pr_typelevel (pr_type,pr_level),
KEY pr_level (pr_level),
KEY pr_cascade (pr_cascade)
) TYPE=MyISAM ;
Version 1.15.1:
CREATE TABLE lamp_page_restrictions (
pr_page int(11) NOT NULL,
pr_type varbinary(60) NOT NULL,
pr_level varbinary(60) NOT NULL,
pr_cascade tinyint(4) NOT NULL,
pr_user int(11) default NULL,
pr_expiry varbinary(14) default NULL,
pr_id int(10) unsigned NOT NULL auto_increment,
PRIMARY KEY (pr_page,pr_type),
UNIQUE KEY pr_id (pr_id),
KEY pr_typelevel (pr_type,pr_level),
KEY pr_level (pr_level),
KEY pr_cascade (pr_cascade)
) TYPE=MyISAM;
============================
I do not see a difference over the last few month. I installed
- mediawiki-1.11.0.tar.gz: 2008-01-03
- mediawiki-1.15.1.tar.gz: 2009-07-16
and I think it was the same in "mediawiki-1.10.1.tar.gz". But you can
take a look yourself:
"maintenance/tables.sql" contains
===
-- Used for storing page restrictions (i.e. protection levels)
CREATE TABLE /*$wgDBprefix*/page_restrictions (
===
and as far as I can tell, they did not change at all since
"mediawiki-1.10.1.tar.gz".
Regards,
Claus
Hello,
I have some problem with Tex when i change of version 1.10.2 (on windows) to
the actual version (on Linux):
1 - The fonts size is more big : how can i reduce the size ?
2 - The transparence of math disappear : how can i put on ?
Thanks you very much.
Nicolas.
> Is this just reserved syntax for a planned feature, or should it
> actually work?
I do not think it works. I googled and and only found your post:
http://www.gossamer-threads.com/lists/wiki/mediawiki/178667?page=last
and some extensions.
I looked at the code of "importDump.php", but could not find anything
useful there, either.
I would try a different approach.
When you run "importDump.php" you could modify it or your script and add:
"INSERT INTO mw_page_restrictions
(pr_page, pr_type, pr_level, pr_cascade, pr_user, pr_expiry, pr_id)
VALUES(4, 'edit', 'sysop', 0, NULL, 'infinity', 1);"
4 = "page_id" in table "mw_page"
"autoconfirmed" could be used instead of "sysop", if you want to grant
access to registered users.
But keep in mind:
"MediaWiki is not designed to be a CMS, or to protect sensitive data.
To the contrary, it was designed to be as open as possible. Thus it
does not inherently support full featured, air-tight protection of
private content. But with the massive increase of MediaWiki use in
corporate intranets and the many CMS-like features emerging, demand
for tighter security is emerging."
(Quote from "Security issues with authorization extensions")
http://www.mediawiki.org/wiki/Security_issues_with_authorization_extensions
Regards
Claus