Does anyone know how to exclude pages from the Recent Changes page in mediawiki? I have a testing page where users can play with syntax and formatting etc. but don't want every little change to show up on the recent changes page.
thanks
You can use the SpecialRecentChangesQuery hook to exclude the specific page by title, like this:
$wgHooks['SpecialRecentChangesQuery'][] = 'rcExcludeSandbox';
function rcExcludeSandbox( $conds ) {
$dbr = wfGetDB( DB_SLAVE );
$conds[] = 'rc_title != ' . $dbr->addQuotes( 'Sandbox' );
return true;
}
This will prevent all changes on the page "Sandbox" from appearing in Special:RecentChanges.
If you don't mind writing some PHP, consider using the http://www.mediawiki.org/wiki/Manual:Hooks/OldChangesListRecentChangesLine hook. If you set $s to an empty string for a given page, then those edits shouldn't appear in Special:RecentChanges.
Easiest would be to put your page in a different namespace, and not search it by default. Unfortunately that functionality isn't in the current version of Mediawiki.
I think you have to use Namespace Manager, It doesn't look like it is finished, but you could give it a shot. It seems like the plan is to add it to a future version.
You could just make a page named Sandbox, and then allow users to edit that page. If you use Enhanced Recent Changes all those edits will appear together, so it won't bother you too much.
My solution is a separate wiki instance. It is not that hard to set up and then you can also test functional changes in isolation as well.
Related
I am creating a MediaWiki plug-in that lists many files. For each file, I want to print a [Talk] or [Discuss] link. (It seems that the original name was talk but that it was renamed to discuss.) These links should be red if the page does not exist and blue if it does exist.
There should be a way to add such links in OutputPage.php, but I can't figure it out.
I know about these functions "foo":
$page = WikiPage::factory ( $title )
$talk = $title->getTalkPage()
But I'm not sure how to get $title from foo.
I'm also not sure how to change $talk into the appropriate HTML. I'd rather not add it to the output stream, because I'm building a lot of HTML separately, but I suppose I can refactor so that instead of passing my strings around, I pass around a handle to the output.
Why don't you use OutputPage::addWikiText() to add the appropriate link without worrying about the technical details: [[{{ns:11}}:Foo|Text]] for example.
Alternatively you can get $title from OutputPage::getTitle() for the current page, or from Title::newFromText() for any title you want to use. You can get $talk directly by specifying the correct namespace constant, which might be even easier than the trip via a WikiPage object.
Correct styling for the link can be done with the helper methods Title::exists() and one of the appropriate helpers for generating urls for pages.
See also https://doc.wikimedia.org/mediawiki-core/master/php/classTitle.html
i'm running a small wiki and our users would like an interface they find less confusing. the complaint is that a page titled something like 'Big_news' displays as a redlink if the link is 'Big News' or 'big news' or some other upper/lower case permutation, and they'd like these to appear as normal-coloured links if the page exists. when a user clicks on the link, the appropriate page is displayed correctly, but it would be better to see that the page already exists beforehand.
i've tried to implement solutions such as those presented here, here, and here, but they don't work -- links still display as redlinks on the page. [indeed, i think some of the articles are out of date ; mediawiki 1.27 doesn't seem to have the tables mentioned in them.]
any ideas how i might go about doing this ?
You could look at how $wgCapitalLinks is being used. Chances are, all-lowercase titles will need special casing in the same places where code needs to be branched based on that setting.
You could hook on HtmlPageLinkRendererBegin and use the link target to run a database query to find any case-insensitive matches for the page name (on page title, and it'd have to do this only for internal links), and then replace the target if there's a match.
thanks for the tip, #Sam Wilson. that looks like an interesting function, but unless i miss my guess, i'd have to query the database for every single link in a page -- correct ? if so, i think performance would suffer. anyway, that hook didn't seem to work for me [mostly because my unfamiliarity with mediawiki left me scratching my head...]. the solution i came up with is as follows :
1- add the variable $wgLinksIgnoreCase to your LocalSettings.php file. set this to true if you want link displays to be mapped case-insensitively.
2- modify the file includes/parser/LinkHolderArray.php as follows [diff accurate for wikimedia version 1.29] -
283a284
> global $wgLinksIgnoreCase;
370a373,376
> if (!empty($wgLinksIgnoreCase)) {
> $mapper = array_combine(array_keys($colours), array_keys($colours));
> $mapper = array_change_key_case($mapper);
> }
373a380,381
> if (!empty($wgLinksIgnoreCase) && isset($mapper[strtolower($pdbk)]))
> $pdbk = $mapper[strtolower($pdbk)];
as i say, i'm not very familiar with the software, so if anyone who is familiar with it finds a more elegant solution, feel free to chime in.
My extension renders additional links on a page (that is adds some <a href='...'>...</a> to the page text (in HtmlPageLinkRendererEnd hook)).
See small arrows in https://withoutvowels.org/wiki/Tanakh:Genesis_1:1 for an example. The arrows are automatically added by my extension (sorry, at the time of writing this the source code is not yet released).
The problem is that red/blue ("new") status is not updated for links which I add.
Please explain how to make Wikipedia to update color of my links as appropriate together with regular [[...]] MediaWiki links.
My current workaround is to run php maintenance/update.php. It is a very bad workaround. How to do it better?
Normally you'd use LinkRenderer to create the links and LinkBatch to make the page existence check efficient (you don't want a separate SQL query for each link). You can't really do that in HtmlPageLinkRendererEnd since you only learn about the links one by one.
The way the parser deals with this is that it replaces links with a placeholder and collects them in a list, then after parsing is mostly done it looks them all up at once and then switches the placeholders with the rendered links. You can probably hook into somthing that happens between the two (e.g. ParserAfterParse), get the list of links from the parser and use them to build a list of your own links.
With valuable help of Wikitech-l mailing list, I found a solution.
The solution is to use ParserAfterTidy hook.
public static function onParserAfterTidy( &$parser, &$text ) {
# ...
$parserOutput = $parser->getOutput();
foreach($parserOutput->getLinks() as ...) {
# ...
$parserOutput->addLink( Title::newFromDBkey(...) );
}
}
To offer a mobile version of an existing mediawiki installation I was looking for a practicable way to remove all images from output. The most preferred solution would be one where the generated html would no longer contain the image-tags.
As I was not able to figure out a clean solution I moved the images to a different server and disabled $wgForeignFileRepos and $wgAllowExternalImages in this version.
Unfortunately - while the images are not shown - there appears a placeholder box containing the image's name and a (now not functioning) link to it.
Do you know about a way to get rid of the images without using css/js or a way to bring my approach to completion?
You could use this javascript mobile browswer detection and then on detection it runs the following javascript code.
var imagesremove = document.getElementsByTag('img')
imagesremove.parentNode.removeChild(imagesremove);
There are probably better solutions, but you can override the ImageBeforeProduceHTML hook to make images generate empty output:
$wgHooks['ImageBeforeProduceHTML'][] = function( &$skin, &$title, &$file, &$frameParams, &$handlerParams, &$time, &$res ) {
$res = '';
return false;
}
...or something more fancy, such as returning a link to the image instead of an actual <img> tag.
Depending on your wiki's caching settings, you might have to purge the page cache afterwards, e.g. by setting $wgCacheEpoch.
I have what I feel is a very simple question about Umbraco, but one that has as of yet no apparent answer.
I have a razor template, standard stuff, with # displaying variables and some inline C# code.
At one point in the template I use:
#Umbraco.RenderMacro("myCustomMacro");
no problems there, everything works as expected.
Now, this macro is inserted on every page (it's in the master template) but I have a page property that allows the content authors to turn it on and off via a check box in the page properties, again so far so good everything works perfectly.
However I now find that for a certain "document type" this component MUST be displayed, so I've been trying to find a way to perform that check.
Now in my mind, this should be as simple as doing something like this:
#{
if(CurrentPage.documentType == "someDocTypeAliasHere")
{
//Render the macro
}
else
{
// Render the macro only if the tick box is checked
}
}
as I say, this is (or I believe it should be anyway) a very simple operation, but one that so far does not seem to have a result.
What Have I tried so far?
Well apart from reading every page on our-umbraco that mentions anything to do with razor & the #CurrentPage variable, Iv'e been through the razor properties cheat sheet, and tried what would appear to be the most common properties including (In no specific order):
#CurrentPage.NodeTypeAlias
#CurrentPage.NodeType
#CurrentPage.ContentType
#CurrentPage.DocumentType
and various letter case combinations of those, plus some others that looked like they might fit the bill.
Consistently the properties either don't exist or are empty so have no useable information in them to help determine the result.
So now after a couple of days of going round in circles, and not getting anywhere I find myself here..
(Please note: this is not a search the XSLT question, or iterate a child collection or anything like that, so any requests to post XSLT, Macros, Page templates or anything like that will be refused, all I need to do is find a way to determine the Document Type of the current page being rendered.)
Cheers
Shawty
PS: Forgot to mention, I'm using
umbraco v 4.11.8 (Assembly version: 1.0.4869.17899)
Just in case anyone asks.
In Umbraco 7 use currentPageNode.DocumentTypeAlias
In Umbraco 7.1 I use: #if (#CurrentPage.DocumentTypeAlias == "NewsItem")
think you do actually need to create a node each time when you are on the page to access the pages properties like nodetypealias and stuff, try this i have the same kind of functionality on my site, http://rdmonline.co.uk/ but in the side menu where depending on the page/section it shows a diff menu links.
#{
var currentPageID = Model.Id;
var currentPageNode = Library.NodeById(currentPageID);
if (currentPageNode.NodeTypeAlias == "someDocTypeAliasHere")
{
//Render the macro
}
else
{
// Render the macro only if the tick box is checked
}
}
Let me know if this works for you.
This is a bit unrelated to this post, but searching Google brought me to this post, so I thought I'd share in case anoyne else is dealing with this issue: In Umbraco 7, to get all content in the site for a specific type:
var articles = CurrentPage.AncestorOrSelf(1).Descendants()
.Where("DocumentTypeAlias == \"BlogPost\"").OrderBy("CreateDate desc");
If your razor view inherits from Umbraco.Web.Mvc.UmbracoViewPage, you could also use UmbracoHelper:
#if (UmbracoHelper.AssignedContentItem.DocumentTypeAlias.Equals("NewsItem")) { ... }
Querying for a specific DocumentType is also easy:
UmbracoHelper.AssignedContentItem.Descendants("NewsItem")
This code will recursively return the list of IPublishedContent nodes.
If you wish to use this list with your specific DocumentType information, these items would have to be mapped to the specific type. Other than that, IPublishedContent gives you the basic information for the nodes.
I've later saw that you have been using an older version of Umbraco. :)
This implementation is only for v7.