In a message dated 10/21/2006 12:31:54 P.M. Pacific Standard Time,
hennar(a)gmail.com writes:
the simpelest thing to do is either write a css from scratch/based on
monobook where you 'hide' those tabs (visibility:hidden;
display:none), only thing you need to know is how to use css.
The other option is designing a custom skin, you'll need to know some
php&html for that, examples can be found in /skins/
henna
Thanks, henna. I've already customized monobook quite a bit, and tweaked the
css for this particular application. But your suggestion does inspire a new
line of thinking -- I could designate alternate classes for the tabs in css
that include display:none then call classes that show or hide various tabs. My
thoughts were more along the lines of simply revising the php that calls the
tabs, but per your suggestion integrating display:none styles might be part
of that schema.
I've really not started plodding through the instantiation logic for the
tabs yet, except to remove one tab on protected pages. Knowing some php and html
isn't enough. The challenge is to apply what knowledge I have, and to develop
some familiarity with MediaWiki architecture. Part of that process involves
searching to see if existing schemas are already available, to avoid
duplicating work already done and to take advantage of the work of more experienced
programmers, or of those more familiar with MediaWiki. I haven't found any
examples in /skins/ that do what I described -- in fact such examples would not
be found there because skintemplate.php, and the tab instantiation logic it
exposes is shared by all skins.
Skinstemplate.php is found in /includes/ and I have not located any
alternative logic in alternate skintemplate.php files so far. That's what I'm asking
-- has anybody released a revised /includes/skintemplate.php that minimizes
instantiation of "edit" and "history" tabs to appear only on those pages and
for those editors who are approved for editing?
The Blacklist Extension at WikiIndex
<http://www.wikiindex.com/Wiki_Index>recently stopped working without
any kind of error message. We loaded the
latest version of the Extension which was supposed to split the list if it
became too large to process per Brion Vibber's post on the 18th of Sep. It
still does not work and fails silently with no errors.
Our configuration is set to use the MediaWiki blacklist and a local
blacklist, the local blacklist is very small. Neither the WikiMedia list or
the local list will block anything.
Any help appreciated in isolating the problem.
Configuration:
------------------------------------
MediaWiki: 1.6.5
PHP: 4.4.4 (apache)
MySQL: 4.0.25-standard
Extensions:
Parser hooks:
CharInsert by Brion Vibber
DynamicPageList2 (version 0.6.3), hack of the original DynamicPageList
extension featuring many Improvements, by IlyaHaykinson, Amgine, Unendlich,
Cyril Dangerville
Inputbox by Erik Moeller
Other:
SpamBlacklist by Tim Starling
Extension functions:
wfDynamicPageList2, registerExtensions, registerInputboxExtension and
setupSpecialChars
Parser extension tags:
<DPL>, <thumbnail>, <inputbox> and <charinsert
----------------------------------
John Stanton jrs.oregon(a)gmail.com
Those tabs at the top of a page in default MediaWiki installations interfere
with my design goals. In general, I want pages to focus on the content of
pages, not on the function of a site or of a "community." I nixed the "view
source" tab which appears for the vast majority of users who will not have edit
access, though that control of access is still dependent on page protection
instead of on granular permissions. Eventually I will move most article
development into protected namespaces, or use another approach to regulation
editorial access.
The glitch now is that pesky "history" tab. The vast majority of readers who
see a tab that says "history" over an article about baseball, for example,
will expect that tab to lead to information about the history of baseball, not
to a page of unfathomable links to "cur" and "Talk" and "contribs".
Now, it's not that I don't need version control. That's why I selected
MediaWiki -- it provides for version control and for shared editorial access. I
just don't need to wear my choice in software on my sleeve.
My question is, has anyone developed other schema for rendering these tabs?
A left column placement would be an easy way to reduce the visibility of the
tags, but that doesn't settle ambiguity about what they mean, and it doesn't
negate the implication that version control (history) is relevant to the
average user. My first best option would be to have the history tab appear only
for those with edit privileges on that page. If I go that route, I'll probably
find a way to revise it as I plod along through revising the "edit" tab
logic.
I query here because I doubt I am the only one to have used MediaWiki for
other purposes than to promote the idea that "anybody can edit." Are there other
working schemas in circulation for rendering these tabs?
Hi,
Does anyone know how to add a special page in the toolbox section?
I got a problem with UNIQ QINU tags (MW 1.6.7). I usually get them on
wikipage and only last tagged version is working
I found some info on this problem here:
http://meta.wikimedia.org/wiki/MediaWiki_extensions_FAQ#How_do_I_render_wik…
However when I tried to render a wikipage using methods mentioned there I
got a blank page only.
Is there a tutorial anyway what should be changed or adjusted?
thx for answers
thx
I'm trying to install MediaWiki 1.7.1 and the process hangs partway
through. After the "Initializing Data..." part, it just cuts off. My
Apache error logs report nothing, and when I did some debugging, I
found that it hangs on line 820 on config/index.php:
$u = User::newFromName( $conf->getSysopName() );
Delving into that, the problem was specifically in the newFromName()
function...
A bunch of delving into that led me to line 461 on
include/Database.php . Oddly enough, if I change the new_link part of
mysql_connect() to be false, the install finishes (but then I get
blank screens whenever I try to use the resulting wiki).
It's entirely possible that there is some setting in php that is
causing this problem, but I don't know where to look. As said before,
nothing shows in my error logs, and I do have display_errors set to
on.
As is the norm, here is the text of the install page:
Please include all of the lines below when reporting installation problems.
* PHP 5.1.4 installed
* Found database drivers for: MySQL
* PHP server API is apache; ok, using pretty URLs (index.php/Page_Title)
* Have XML / Latin1-UTF-8 conversion support.
* PHP is configured with no memory_limit.
* Have zlib support; enabling output compression.
* Neither Turck MMCache nor eAccelerator nor APC are installed, can't
use object caching functions
* GNU diff3 not found.
* Found GD graphics library built-in, image thumbnailing will be
enabled if you enable uploads.
* Installation directory: /home/wheeloft/public_html/wiki
* Script URI path: /wiki
* Environment checked. You can install MediaWiki.
* Warning: $wgSecretKey key is insecure, generated with mt_rand().
Consider changing it manually.
Generating configuration file...
* Database type: MySQL
* Loading class: DatabaseMysql
* Attempting to connect to database server as wheeloft_wikiuse...success.
* Connected to 5.0.24-standard
* Database wheeloft_wiki exists
Warning: mysql_query() [http://www.mysql.com/doc]: Table
'wheeloft_wiki.wot_cur' doesn't exist in
/home/wheeloft/public_html/wiki/includes/Database.php on line 620
Warning: mysql_query() [http://www.mysql.com/doc]: Table
'wheeloft_wiki.wot_revision' doesn't exist in
/home/wheeloft/public_html/wiki/includes/Database.php on line 620
* Creating tables... using MySQL 4 table defs... done.
* Initializing data...
I've recently migrated a 1.5.8 Wiki to a new machine. In the process, I
upgraded to 1.8.2, added memcached, eaccelerator, and squid (in
accelerator mode).
Software in use:
# Gentoo Linux
# Apache 2.0.58
# PHP 5.1.6-r4
# Memcached 1.1.12-r2
# eAccelerator 0.9.5
# SQUID 2.6 (STABLE3)
# MySQL 5.0.24-r1 (with big-tables max-idx-128)
# MediaWiki 1.8.2
I did a lot of testing using LoadRunner (commercial performance test
tool from Mercury) with each change/addition of the above. Without
question, squid makes an enormous (positive) impact on performance,
particularly under load.
So, all is well and good with my new site, except...
Saving newly created pages and uploading files takes FOREVER when squid
is turned on.
With no squid, saving a new page takes about 1 second. With squid,
saving a new page takes about 105 seconds.
I'm sure it's just a squid configuration problem, but I'm a squid newbie
and don't know where to look. Below is my squid.conf, created by
pasting together options I found on the Web + things that looked
important from the man page and default config file.
Any help debugging this will be appreciated.
# squid.conf
http_port 192.168.1.1:80 vhost
cache_peer 127.0.0.1 parent 80 0 no-query originserver
hierarchy_stoplist cgi-bin ?
acl QUERY urlpath_regex cgi-bin \?
cache deny QUERY
acl apache rep_header Server ^Apache
broken_vary_encoding allow apache
cache_mem 256 MB
maximum_object_size_in_memory 512 KB
cache_replacement_policy heap GDSF
cache_dir ufs /var/cache/squid 1024 16 256
logformat combined %>a %ui %un [%tl] "%rm %ru HTTP/%rv" %Hs %<st
"%{Referer}>h" "%{User-Agent}>h" %Ss:%Sh
access_log /var/log/squid/access.log combined
cache_log none
cache_store_log none
emulate_httpd_log on
url_rewrite_host_header off
request_body_max_size 100 MB
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern . 0 20% 4320
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl web_ports port 80
http_access allow web_ports
http_access allow manager localhost
http_access deny manager
acl purge method PURGE
http_access allow purge localhost
http_access deny purge
acl UPLOADS url_regex /uploads/./
no_cache deny all UPLOADS
http_access deny all
cache_mgr squid_cache@stweb
mail_program mail
append_domain .mydomain.com
forwarded_for off
coredump_dir /var/cache/squid
I have already installed a mediawiki 1.8.2 with very short urls installed,
all is working fine, but the preview page isn't working, when i try to
preview changes when im modifying i get a blank page.
I search a lot but only get information to do the very short urls, nobody
has the same problem.
My .htaccess is:
RewriteEngine on
RewriteRule
^[^:]*\.(php|src|jpg|jpeg|png|gif|bmp|css|js|inc|phtml|pl|ico|html|shtml)$ -
[L,NC] RewriteRule ^index.php?title - [L] RewriteRule ^(.*)\&(.*)$ $1\%26$2
RewriteRule ^(.+)$ /index.php?title=$1 [L,QSA]
(ive tried 3 different ones with the same results)
And my LocalSettings.php is:
$wgScriptPath = "";
$wgScript = "/index.php";
$wgRedirectScript = "/redirect.php";
$wgArticlePath = "$wgScriptPath/$1";
If anybody knows i will be thankful.
I have mw 1.6.8 and cant upgrade to 1.8 because our server doesnt support php 5 yet. Is there a way Parserfunctions can work together with Cite ? A number of people are having this problem, where they cant get these two extensions working together in 1.6.
I would be grateful if anyone could tell me of a workaround they found for this, particularly for the IF and IFEXPR statements. I tried to make it work using the old Qif Template but it didnt work. I'll keep trying though.
thanks
Eric
---------------------------------
Get your own web address for just $1.99/1st yr. We'll help. Yahoo! Small Business.
WikiFeeds version 0.4 is now available.
Major new features:
* Disk-based caching of feeds
* Ability to localize using MediaWiki messages interface
If you are not familar with WikiFeeds, it generates RSS and ATOM 1.0 feeds
not found in the default MediaWiki install, such as recent changes in a
category and user watchlists.
More info is available at http://meta.wikimedia.org/wiki/WikiFeeds
I plan to include private watchlist feed support in version 0.5. Before
this happens, I'm trying to figure out the best way to do this. I would
like to go with the private token approach. For example,
http://en.wikipedia.org/w/Special:WikiFeeds/atom/watchlist/IndyGreg/token/0….
However, I'm not sure how to generate and/or store the token. Is the
user_token field in the user table safe to use for this purpose, or should I
generate something on my own?
If you have any issues, questions, or feature requests, please e-mail me at
the address below.
Gregory Szorc
gregory.szorc(a)gmail.com
Can someone help me install mwsearch in Windows.
I currently have the source from svn. I have dotLucene installed. But
I have no idea how to install mwsearch.
Thanks
--
Sin Hang Kin.