i'm confused by the 'post a comment' inputbox. what should i put in the edit box? the title of the page to post a comment to?
Can i have an easy 'comment on this page' link at the bottom of each page?
Chief architect, openQRM group leader,
R&D, Qlusters Inc.
+972-3-6081994 Fax: +972-3-6081841
www.openqrm.org - Data Center Provisioning
While searching for a "killer app" for convincing my colleagues of the
advantages of a wiki (see the thread on corporate wiki success factors),
I realized that calendaring and scheduling might be a very good thing to
This way everyone could, for example, enter their periods of absence
(e.g. vacations, out-of-office meetings etc.) in the wiki without the
hassle we currently have with these issues (we're mostly using an Excel
sheet for that at the moment).
However, I wonder how best to present the respective data.
Using the EasyTimeline extension probably wouldn't be a good thing for
starters, as its use is a little more complicated than the basic wiki
A huge table might do the job, but its "source code" (i.e. wiki syntax)
would probably look like a huge mess to most of my colleagues.
So that leaves me with an ordinary sequential list - maybe with years
and months as (sub-)headings? The whole thing might look something like
Hmm, come to think of it, a shared Excel table might actually be better
then - also because it'd be easier to highlight weekends and holidays
What do you think of my assessment of this situation - any ideas?
Thanks a lot in advance!
Every FUCKING JERK is publishing these Emails from this mailing list all
over the world. There are coming more and more SHIT SITES which are
publishing every word I am writing here on its dammed websites without my
permission. Every open webforum is more private than this list.
this is defenetly the reason, why noone uses this mailing list anymore.
Perhaps you should write near the subscription button: "note, everything you
write here is published on several sites all over the world"
I will defenetly unsubscribe from now on.
I have a question, is it possible to create a drop down list of categories when a new page is created? To allow users to classify their article under one or more categories? Even a small change in the spelling will cause the article to be classified under a different area..... ideas??
Sorry to be a pain but I have a problem, and I almost thought I had fixed
it, following the instructions you can get by following this:
If you go to next message a few times you get 2 commands, and later 1
command, for a total of 3 commands to run. So I read it, and not being the
MySQL, or SQL anything for that matter, expert I can assume some MediaWiki
users are, I need some assistance converting this solution into something
usable for MySQL. The problem is, there is no "drop constraint" in MySQL.
There is "add constraint", but no drop. So this leaves me in a kind of a
If I go to the page that I want to delete, it deletes all of the content but
if I revisit it, it says: "This page has no text, you can search for the
page or edit it" or something to that effect.
Also mentioned in the article above, is this issue has been resolved in
subversion 15672. Although it doesn't mention what version the issue is in
anyway. Seeing as I got my version last week, Friday, December 15th 2006 I
do believe, I think I should at least have that. For arguments sake, I have
MediaWiki 1.8.2..... Assuming that subversion 15672 is 1.8.15672, it looks
like it isn't resolved, unless, I have a different version altogether.
So I'm stuck with an empty page and a Special:Categories reference to a page
that doesn't even have a [[Category:name]] to reference it. It's completely
What I'm really asking is: What can someone with MySQL do to resolve this
issue? Since it gives me a syntax error at "constraints" when I tried the
solution provided in a response to the link above. (The solution is linked
from there but that is the parent message)
Any ideas or solutions would be greatly appreciated. I thought about
dropping foreign keys but like I said, I'm no SQL expert and you usually
make constraints on foreign keys.
my Mediawiki 1.7 can't display any UTF-8 characters. My MySQL server
defaults to UTF-8 and my tables usually have collation latin1_bin. This
is exactly how things were set up when I installed Mediawiki. However,
my interwiki links did not work until I changed the collation of
column iw_prefix to latin1_swedish_ci. Even now I cannot use any UTF-8
characters in Mediawiki. I have another install that runs most columns
(not all) on latin1_swedish_ci and there UTF-8 seems to work fine. I'm
now wondering if I have to manually change my columns on the
non-working install to latin1_swedish_ci or if there is also a way of
getting this to work with the latin1_bin columns.
Any hints on this?
I have installed Mediawiki 1.8.2 running on Windows 2003, served up by
PHP 5.2 on IIS 5. I have attempted to integrate this with Active
Directory, with lots of help from Ryan Lane, but have thus far been
unsuccessful. It looks like such integration would require Openldap
and probably more work that it is worth.
An easier approach, it seems to me, would be to have IIS do the
authentication and pass the information to Mediawiki. This is possible
with Windows Integrated authentication. The username is available in
PHP under $_SERVER['REMOTE_USER'] or get_current_user(). The next
trick is to pass this onto Mediawiki.
I tried the code below but it only generates an HTTP 500 error when
parsing InitUser(). This might be because of versioning, because the
example is for MediaWiki 1.5.5 and I have 1.8.2.
It also seems rather round-about to create an WebRequest and submit it
to the form, which then does the login. Maybe I am missing something
here, though, for I am rather rough with PHP.
So, in sum, how do I simply and easily modify Mediawiki to use IIS's
J Wolfgang Goerlich
Custom per user navigation portlet
Anyone done this?
Any ideas how to simply do it?
To allow users to bookmark site pages they often visit. So they can
create quick and deep navigation for their specific topic of interest
within a wide but deep focus wiki such as Wikiversity.org.
* Custom nav to appear in left sidebar below the Search box
but above the Toolbox.
* Customized per logged-in user, such as how only user
Foo can edit User:Foo/monobook.css, maybe at User:Foo/nav.
* Parsed like a normal wiki page instead of like MediaWiki:Sidebar
because normal users don't want to learn non-standard markup.
* Other users could use Foo's custom nav portlet by
transcluding it into their own User:Name/nav by typing there
* Interest groups could collaboratively create and maintain group
specific custom nav portlets, eg
Template:nav_English_as_a_second_language, to transclude into
their interest group pages and or individual User:Name/nav
Currently in standard MediaWiki a user Foo can put "bookmarks" in
1. browser bookmarks
2. Links in User:Foo page or subpages thereof
3. Links in page Whatever for benefit of everyone
4. Category:Whatever page by labeling the page [[Category:Whatever]]
5. Links in Template:Whatever
However, standard browser bookmarks are too messy as we all know and 2,
3, 4 and 5 are not as convenient to click as left sidebar would be.
Deep wide wiki's such as Wikiversity.org and other deep wide Open
Educational Resources wiki's are a nuisance to navigate.
A *custom per user navigation portlet* could be an enormous practical
benefit to wiki's that have not just wide but also *deep* topics, such
as Wikiversity. Wikipedia only goes wide, not deep, and is manageable
because each encyclopedia page has a unique, language defined, term or
phrase that defines it as encyclopedic -- going deeper is not an
encyclopedia's mission but is the mission of many other wikis.
Has anyone tried this?
Ideas how to simply write it in PHP as a MediaWiki extension?
Happy New Year!
Roger Chrisman :-) http://Wikigogy.org - free resources
for teachers of English as a second or foreign language
How would I go about adding memcached configuration to an existing
MediaWiki 1.8 installation? I have scrounged config/index.php, and it
seems I haven't found it (even though it probably was in front of my
face all the time).