Im running the lsearchd daemon by just running .lsearchd in the terminal - and it all works.
But when I close that window, it stops.
How did I run it in silent mode, or as background, or some way that is not dependent on my window staying open?
Thanks!
Hi,
another very specific problem/question: I would like to transclude talkpages from certain pages but I do not want that they influence the behaviour of the the TOC list of the main article. Is there a way to format the headings of transcluded pages in such way that they do not appear in the TOC list of their new evironment? Ideally, I would like to be able to transform ==...== into '''...''' if the page is transcluded.I tried to achieve that by using the DPL extension, but as far as I know now there is no provision for such a case, since you cannot influence the behavious of all headings and sub-headings at random. Is there another solution/extension/hack?
Thx in advance
B.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This is a security and bugfix release of MediaWiki 1.16.0 and
MediaWiki 1.15.5. Download links are given at the end of this email.
A data leakage vulnerability was discovered, affecting MediaWiki 1.8
and later. Public caching headers were incorrectly set on API
responses containing private data. By means of a CSRF-style attack,
this can lead to the disclosure of various types of private data
stored on a wiki. All users are advised to upgrade. Full details can
be found at:
https://bugzilla.wikimedia.org/show_bug.cgi?id=24565
A cross-site scripting (XSS) vulnerability was discovered in
profileinfo.php. The vulnerability is only exposed when the script is
explicitly enabled in LocalSettings.php, with $wgEnableProfileInfo = true.
A register_globals arbitrary inclusion vulnerability was discovered in
the 1.16 beta release series, in MediaWikiParserTest.php. This
vulnerability does not affect any stable MediaWiki release. It only
affects wikis which have PHP's register_globals feature enabled,
despite our strong advice to the contrary. Apache installations with
AllowOverride enabled may be protected against this vulnerability,
since there is a .htaccess file with "Deny from all" in the relevant path.
In both releases, the interface text was updated with new translations
from translatewiki.net.
Full release notes for 1.15.5:
<http://svn.wikimedia.org/svnroot/mediawiki/tags/REL1_15_5/phase3/RELEASE-NO…>
Full release notes for 1.16.0:
<http://svn.wikimedia.org/svnroot/mediawiki/tags/REL1_16_0/phase3/RELEASE-NO…>
Upgrade FAQ:
http://www.mediawiki.org/wiki/Manual:FAQ#Upgrading
**********************************************************************
We are proud to announce the first stable release of the 1.16 series.
Selected changes that may be of interest since MediaWiki 1.15 are:
* Watchlists now have RSS/Atom feeds. RSS feeds generally are now
hidden, since Atom is a better protocol and is supported by virtually
all clients.
* It's now possible to block users from sending email via
Special:Emailuser.
* The maintenance script system was overhauled. Most maintenance
scripts now have a useful help page when you run them with --help.
* AdminSettings.php is no longer required in order to run maintenance
scripts. You can just set $wgDBadminuser and $wgDBadminpassword in
your LocalSettings.php instead.
* The preferences system was overhauled. Preferences are stored in a
more compact format. Changes to site default preferences will
automatically affect all users who have not chosen a different preference.
* Support for SQLite was improved. Some broken features were fixed,
and it now has an efficient full-text search.
* The user groups ACL system was improved by allowing rights to be
revoked, instead of just granted.
* A new localisation caching system was introduced, which will make
MediaWiki faster for almost everyone, especially when lots of
extensions are enabled.
By default, this new system makes a lot of database queries. If your
database is particularly slow, or if your system administrator limits
your query count, or if you want to squeeze as much performance as
possible out of Mediawiki, set $wgCacheDirectory to a writable path on
the local filesystem. Make sure you have the DBA extension for PHP
installed, this will improve performance further.
**********************************************************************
1.15.5
**********************************************************************
Download:
http://download.wikimedia.org/mediawiki/1.15/mediawiki-1.15.5.tar.gz
Patch to previous version (1.15.4), without interface text:
http://download.wikimedia.org/mediawiki/1.15/mediawiki-1.15.5.patch.gz
Interface text changes:
http://download.wikimedia.org/mediawiki/1.15/mediawiki-i18n-1.15.5.patch.gz
GPG signatures:
http://download.wikimedia.org/mediawiki/1.15/mediawiki-1.15.5.tar.gz.sighttp://download.wikimedia.org/mediawiki/1.15/mediawiki-1.15.5.patch.gz.sighttp://download.wikimedia.org/mediawiki/1.15/mediawiki-i18n-1.15.5.patch.gz…
Public keys:
https://secure.wikimedia.org/keys.html
**********************************************************************
1.16.0
**********************************************************************
Download:
http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.0.tar.gz
Patch to previous version (1.16.0beta3), without interface text:
http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.0.patch.gz
Interface text changes:
http://download.wikimedia.org/mediawiki/1.16/mediawiki-i18n-1.16.0.patch.gz
GPG signatures:
http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.0.tar.gz.sighttp://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.0.patch.gz.sighttp://download.wikimedia.org/mediawiki/1.16/mediawiki-i18n-1.16.0.patch.gz…
Public keys:
https://secure.wikimedia.org/keys.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxP4e8ACgkQgkA+Wfn4zXkWIgCgmr9dHmPtQqk+2bdQaHkLGss3
7W8AoJqgkJsurVVzWFBkr3TgrswsWzcd
=L7ad
-----END PGP SIGNATURE-----
I just added a lot of pages to a name space, and I need to enable users to search that name space by default.
I added that namespace as a default to search - And this works for guests.
But all users who are logged in are using their personal settings and this name space is not selected.
How would I go about enabling search in this namespace for all users?
It is fine if I need to do it through SQL.
Thank you, Adam
I have a custom tag called code with an attribute of p.
<code p="test" />
I have a template called code that is very simple
<code p="{{{1}}}" />
[[Category:Has Code]]
when I do this {{code|test}}
It does not render as <code p="test" /> but as <code p="{{{1}}}" />
Any ideas why?
Thanks,
-Adam
Hi,
I would like to add a function/button to the edit window:
like the "nowiki" or "italics" button it should create typographical hyphens (“...”) in the textarea. How could that be done? Or is there some extension to do that?
Thx
Bernhard
Hi All,
I imagine it has previously been discussed, and I've noticed a creep
throughout the repository of people (Jeroen being one of them) doing it. But
we should probably really have everything stylized the same.
I keep the API fairly up to date, and on a similar vein, have been adding
braces across other files as I go along.
Obviously, this gives us the benefit of as much of our code as possible
meeting our Coding Conventions [1], though, might cause some people some
issues, more so with some patches. However, isn't there a svn setting to
ignore whitespace when doing that sort of action?
It'd also be nice if stylize would add braces to one line if's. [2]
Thanks
Sam
[1] http://www.mediawiki.org/wiki/Coding_convention
[2] https://bugzilla.wikimedia.org/show_bug.cgi?id=22621
Is there any way to prevent the "Pages with too many expensive parser
function calls" category from examining pages in the User namespace?
Pages in User space satisfying the expensive parser function call limit
are generally not accessed by the general readership and therefore are of
less concern than those in the main article namespace.
For example, if you look at the expensive parser function call category
on Wikipedia (http://en.wikipedia.org/wiki/
Category:Pages_with_too_many_expensive_parser_function_calls) roughly
half the pages are in the user namespace. It would be useful to remove
these pages from the category.
--
-- Dan Nessett