Hello,I have a page with a very long title
mysite.com/Namespace:This_page_title_is_so_long_that_the_email_client_broke…
In my case, the link became mysite.com/Namespace: and the page title was not
linked
The result of the link is a "bad title" error,
try http://en.wikipedia.org/wiki/Category: for example
I use htaccess with rewrite rules and I tried, unsuccessfully, to make
visitor falling back on a better page than this "bad title" error.
My rewrite rules look like :
RewriteRule ^/$ /Accueil [R]
RewriteRule ^/?Namespace:$ /Namespace:The_fallback_page [R]
# do the rewrite
RewriteRule ^/?(.*)$ /index.php?title=$1 [L,QSA]
you guess it, I have a problem (else I won't ask you some help ^^) with the
rule
RewriteRule ^/?Namespace:$ /Namespace:The_fallback_page [R]
I tried with %3A instead of :
I tried with [L], [L,QSA]
...
and still the "bad title" error :(
What's wrong with my rewrite rule ?
Thanks in advance for your help!
--
Sylvain Machefert
Tous aux Balkans !
http://www.tousauxbalkans.net
Thanks.
In what respect are later history dumps not complete ?
Do you happen to know whom one could contact for recent history dumps ?
On Wed, Apr 8, 2009 at 2:00 PM,
<mediawiki-l-request(a)lists.wikimedia.org> wrote:
> That's only a partial dump. The last full dump was on 20080103. I'm hosting
> a copy:
>
> http://grey.colorado.edu/enwiki-20080103-pages-meta-history.xml.7z
>
> On Tue, Apr 7, 2009 at 10:39 AM, Farkas, Illes <fij(a)angel.elte.hu> wrote:
>
>> Hello,
>>
>> At http://download.wikimedia.org/enwiki/latest the latest enwiki
>> history dump is from 2008-Apr-05. Are there more recent history dumps
>> of enwiki available? Maybe at other URLs or in other formats?
>>
>> Thank you.
I want to setup 4 wikis ol, ml, ssip and v4v with the last 3 sharing the
tables: 'user', 'user_groups', 'interwiki', 'ipblocks' of the first one: ol
I know that I can do this by using only one database for all 4 wikis and
different table prefixes for each. However, I was hoping to be able to
use 4 separate dbs so that I don't "put all my eggs in one basket", so
to speak. My problem is that my host setup automatically assigns a
different username to each db (as well as arbitrarily placing dbs on
different db servers according to availability at the time of creation,
but I can solved that by simply creating, deleting and creating again
until I get them on the same db server). I can also change the passwords
so that they are the same.
So I was looking into the coding to see if I might be able to make a
change to enable the shared situation even though the db usernames are
all different. I found where the code in database.php where function
tableName( $name ) adjusts the input variable (which is the
concatenation of the simple tablename with the database name) to replace
the database name with that of the shared one for those tables which are
in the shared array - set in local settings. This all looks great, but
it occurred to me, how can this work for table JOIN operations? Don't
JOIN operations necessarily need to be relative to the same database?
Is there any working installation with shared tables on different
databases so that it is known that this works? Given that it does
(somehow?), why would it also not be possible to have different
usernames for the different databases?
Do the experts here see any totally impossibility to me setting things
so that for a shared table the username can be changed in addition to
the database name (and perhaps even change the db server as well)? I am
not asking directly how this would done (although such help would
certainly be appreciated), since I am confident that if it can be done
at all, then I can figure it out myself.
Another possibility that I have thought of (particularly if shared
tables do not actually work on different databases, but only on
different prefixed tables within one database, because of the join
problem that I mentioned above) is to place the db parameters of all 4
dbs in the local settings of each (in an array of course) and then
whenever a shared table is *written to* it will be written to on all 4
wiki databases. In this manner they will all be kept in sync. What do
the experts here think of that idea, given that something easier and
less modifying of the system code is not possible.
Thanks muchly in advance for any helpful ideas.
--Paul Wakfer
MoreLife for the rational - http://morelife.org
Reality based tools for more life in quantity and quality
The Self-Sovereign Individual Project - http://selfsip.org
Self-sovereignty, rational pursuit of optimal lifetime happiness,
individual responsibility, social preferencing & social contracting
Hi Platonides,
> >> We need to adapt FlaggedRevs to our custom skin.
> >
> > After further investigating, I realized many things are hardcoded, so I
> > presume I have to hack the FlaggedRevs files :-(. Before doing that,
> > do you know a better approach?
> Well, I didn't find the flaggedrevs at that page. Just the text
> 'Supervisado' which is already into the 'infobar' (I thought you fixed
> it), so don't know what you're trying to accomplish.
That's an example of where the revision box should be placed. The
new version is being currently tested internally.
By default, FlaggedRevs places the box after the title, in the article
body. I managed to move it using JS with DOM, but this is far from
satisfactory for a couple of reasons: non-esssential info before the
article (bad for SEO, because search engines usually ignore JS), and,
well, it's just a JS hack, after all.
For the moment I could live with it (and hopefully users), but it
happens FlaggedRevs forces a hardcoded markup based on a table
and some explicit format (with the style attribute). You can see it in
FlaggedRevsXML.php, function prettyRatingBox.
Javier
Hi all, I need a hint for a best practice about to ad some content to the
TOC.
Basically, as example, could be useful for me to add a list of all subpages
to the TOC, say something like this:
Contents [hide]
* 1 Main sections
o 1.1 Categories
* 2 Browsing the manual
* 3 Improving the manual
Subpages
* fist subpage
* second subpage
At the moment, I made this via template, creating a div with __TOC__ and a
DPL result set containing a list
of all the subpages of the current page, and it works fine. Obviously
clicking the [hide] link hides only the TOC
and not the subpages list. Moreover, the two sections are in different table
(in resulting html).
Thus, the question is: "what is the best approach to synchronize the
behavior of TOC and list of subpages?"
1. probably modify the javascript of TOC?
2. probably modify the parser.php? (I really don't like this!!!!!!)
3. creating an extension to manage such stuff? (but in case, how can I have
a list of subpages via php???)
Thanks for any hint....
G.
--
Giuseppe Briotti
g.briotti(a)gmail.com
"Alme Sol, curru nitido diem qui
promis et celas aliusque et idem
nasceris, possis nihil urbe Roma
visere maius."
(Orazio)
> We need to adapt FlaggedRevs to our custom skin.
After further investigating, I realized many things are hardcoded, so I
presume I have to hack the FlaggedRevs files :-(. Before doing that,
do you know a better approach?
Thanks
Javier
Hello,
At http://download.wikimedia.org/enwiki/latest the latest enwiki
history dump is from 2008-Apr-05. Are there more recent history dumps
of enwiki available? Maybe at other URLs or in other formats?
Thank you.
Hi -
I'm happy for you that the problem is solved. But, to give credit where it
is due, it was the other folks that gave you such good advice.
Best,
Evelyn
-----Original Message-----
From: mediawiki-l-bounces(a)lists.wikimedia.org
[mailto:mediawiki-l-bounces@lists.wikimedia.org] On Behalf Of Ekompute .info
Sent: Monday, April 06, 2009 2:53 AM
To: MediaWiki announcements and site admin list
Subject: Re: [Mediawiki-l] Problem with upgrading form Mediawiki 1.10 to
1.14
Hi Platonides, Mike Daly, Jan Luca, Evelyn Yoder, Tim Starling, and the
many, many others who have attempted to help me solve the problem of
upgrading Mediawiki to Version 1.14.
My, am I glad that the mystery is suddenly solved. I think Mike Daly did
mention it before but I didn't realize that I need to type in again the
table prefix which I thought would create another prefix on top of the
existing one. I was toying with the Mediawiki installer again this morning
and presto! The website went up after I typed in the prefix, "kom".
Thank you very very much for all your kind assistance and moral support. My,
am I glad that I would have no problems upgrading in the future. This phobia
has been with me for far too long!
PM Poon
On Sat, Mar 14, 2009 at 6:19 PM, Ekompute .info <ekompute(a)gmail.com> wrote:
> Hi, I got my webhost to restore my database for me but apparently, my
> website <http://dummipedia.org/Free_Simplified_Online_Encyclopedia> turns
> out the following database error:
>
> A database query syntax error has occurred. This may indicate a bug in the
> software. The last attempted database query was:
>
> (SQL query hidden)
>
> from within function "LocalFile::loadFromDB". MySQL returned error "1054:
> Unknown column 'img_sha1' in 'field list' (localhost)".
>
> Do you think I should consult Bugzilla?
>
> PM Poon
>
_______________________________________________
MediaWiki-l mailing list
MediaWiki-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l