Just FYI, I'm getting this message in MW 1.26 (and presumably earlier). Not sure why recent pages needs skin info.
Use of User::getSkin was deprecated in MediaWiki 1.18.
This actually generate a Fatal Error with recent MW version.
See https://github.com/Inclumedia/RecentPages/pull/4 for my proposal to remove the related line of code
PHP Notice: Undefined variable: displayText in /extensions/RecentPages.php on line 66.... blows up on every call for recent pages, as many times as the limit parameter requests.
What do?
This post was posted by Teststudent, but signed as 63.139.70.66.
Noticed the same. Just remove '$displayText,' from the code. Works all the same.
I'm using <random/> on Main_Page and this wiki doesn't have a lot of articles so more often than not Main_Page is included in the random article list. But it's of course not clickable (because it's listed on its own page) and is therefore printed in bold. Is there a way to exclude e.g. {{PAGENAME}} from the random article list? And maybe do the same for <recent/> too? Thanks!
It was requested that RecentPages be able to exclude pages in a category. That would require a JOIN with categorylinks, so rather than do that, I think it might be more efficient to use page_props; that is, exclude pages that have a certain property key and value. It's often doing a JOIN on that table anyway, so this would be rather efficient.
Should we keep $wgRecentPagesDefaultMinimumLength set to 600 by default, or should we set it to some lower number? It seems like a lot of people forget about it and don't realize it's the reason why they're not getting any results. On the other hand, you get a lot of junk sometimes when you don't set a minimum.
I do not really see a big reason for a change here. However it is possible to explain something decently with fewer words. Perhaps to have more results to begin with and raise the value manually is an approach which at least gives people an initial success experience.
Zero might not be bad either. I developed the extension and I am constantly thinking, "Why am I getting few/no results?" It's usually because of the minimum. For example, a good, pithy quote for the QuoteList might be shorter than 300 characters.
Perhaps it is possible to print a message like e.g. "No pages match the minimum requirment of size." instead to show that it is working.
I thought about that. It should probably be a parameter that defaults to something (stored as a system message), but can be overridden (e.g. with blank). It would be pretty easy to implement, too.
Sorry for maybe a stupid question, but I'm a newbie with mediawiki. I installed the RecentPages Extension and now I try to include it in the main page by adding the code <recent />. The output of the last 6 new pages is correct, however they are not linked but plain text with wikibrackets like this: [ [ I m the newest page| ] ] What am I doing wrong? Thanks.
I think I have fixed it. It required adding the line $html = RecentPages::getDisplayTitle ( $title ); for the situation where there was only one column - i noticed that it was working when there was columns and just copied what worked in the other cases...
To get it to link properly change this code ...
for ( $i = 1; $i <= $numRows; $i++ ) {
$title = $retArray[ $i - 1 ];
if ( !is_null( $title ) ) {
$ret .= "<li>" . $parser->internalParse ( '[[' . $title->getFullText()
. '|' . $html . ']]' ) . "</li>\n";
with this code ....
for ( $i = 1; $i <= $numRows; $i++ ) {
$title = $retArray[ $i - 1 ];
if ( !is_null( $title ) ) {
$ret .= "<li>" . $parser->internalParse ( '[[' . $title->getFullText()
. $html . ']]' ) . "</li>\n";
The change removes the pipe that causes the problem in the last line.
sorry, this is going to be a noob question. where do we exactly add this <recent /> code? i simply edited the main page and add this, nothing happened.
So all you see is <recent />, or is it blank? If you provide a URL, it would be helpful. Thanks.
Please upgrade to the latest version; there have been some recent bugfixes. Thanks.
All your pages were below the minimum length of 600 characters, apparently.
If people don't want a minimum length, then we might as well leave page_len out of the WHERE clause. It's pointless to tell it to exclude every page with less than zero characters. Also, we may want to make the where clause more specific when joining it with page_props and only select the particular properties needed. Then again, that could also hurt performance.
Oh dear, it's doing a separate BedellPenDragon::renderGetBpdProp() for every item, plus it's doing a separate getDisplayTitle() for every item. Not only that, BedellPenDragon::renderRandomPageInCat() does the same thing. Not a big deal, except on templates like ChildWiki:More new articles or ChildWiki:More featured articles. I believe this would be called an O(n) situation. It could get pretty ugly, if the number of articles were to get pretty high.
Probably the most potential for savings is when it's a query that can be done as a LIMIT x (e.g. a new pages feed) or selecting everything in a category, rather than having a WHERE with a bunch of individual pages to select from all over the table (as in the case of random pages). But I'm not sure. I'm no expert on database optimization. Maybe JOINs would make it more efficient; maybe not. Too bad I also know nothing about profiling.
Ugh, I just realized this could get ugly either way, because if I do a join on page_props for the displaytitle and the bpdprop, then I'll end up with multiple rows. So, the WHERE or the JOIN will have to filter for that, I guess (if we're going to reduce the number of rows to a max of three for each title), and then it'll be necessary to make sure each row is only going into the $retArray once. I wonder what the most efficient way will be? Probably to pull all the page_props for a page and just only use the displaytitle and the bpdprop.
Okay, I got rid of the worst of the database inefficiencies, but it's still doing a totally unnecessary O(n) looped query to get the page title objects when it already did a SELECT on the page table for that data. That was just a lazy hack from my more amateurish and short-sighted programming days. Maybe I'll get around to fixing that later.
No such extension "RecentPages"
http://www.mediawiki.org/wiki/Special:ExtensionDistributor/RecentPages
With reference to this edit, isn't it desirable to use subsections for config settings, rather than semicolons? That way people can link directly to them, if they want to.
Well, not even this extensions page does it though it theoretically could. Basically it is a matter of taste.
Added it back in. Another thing. What really hurts are section headings which spread over three lines (FAQ). Not sure if they are linked from other pages. If yes I will revert it back, too.
It does, admittedly, uglify the table of contents. In many cases, it's also probably unnecessary because nothing will in fact link to it. But I find that as instructions get more and more detailed, people tend to want to link to the config setting anchors. We could put another kind of anchor instead, if that would be preferable. Like the kind they use in the glossary.
It would require that the extension code be modified to implement a new parameter to the tag. The page table doesn't have a field for author (aka user), but the recentchanges table does. People have been complaining for awhile that this extension should use recentchanges instead of page; I considered it but there were some complications that would have been involved. For example, if you were to import stuff, you'd need to rebuild recentchanges to make it work.
I think the easiest way to do what you're talking about, without rewriting that part of the code and having a lot of unintended consequences that would need to be addressed, would be to do a JOIN with recentchanges. The structure of the query would be something like:
SELECT page_namespace, page_title from page JOIN recentchanges ON recentchanges.rc_cur_id = page_id WHERE (rc_user = '0' and rc_new = '1');
You'd want to change that query to substitute for the 0 in rc_user = '0' the user.user_id of the user. I guess to get that, you'd use User::newFromName() and then User::getId(). Alternatively, you could just use recentchanges.rc_user_text instead of recentchanges.rc_user, but then I think you run into issues if the user has been renamed.
The only problem is, I've had a lot of trouble figuring out how to use the join parameter of DatabaseBase::select(); despite many attempts, I've only been able to do JOINs using DatabaseBase::query() (see my work at Extension:Chat#WikiChat.php), which is not recommended and would be a step backward from the code we currently have. I could probably figure it out if I did more research (grepping the codebase for other uses of JOIN and following those examples), and undoubtedly I do need to eventually learn how to do that.
Anyway, your options now, as I see them, are (1) pay me .075 bitcoins to bump this work to the top of my list of priorities in which case I'd probably get it done within a day or two; (2) wait until I figure out, in the course of other projects, how to do this JOIN, and then return to implement the feature you're requesting; (3) do it yourself; or (4) get someone else to do it. If you're not already a MediaWiki hacker, gaining the knowledge and skill needed for option #3 might not be such a bad idea, if you plan on doing a lot of work with wikis. Good luck.