Extension talk:RecentPages

PHP Notices flooding my error log

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? 63.139.70.66 21:00, 13 March 2012 (UTC)

Noticed the same. Just remove '$displayText,' from the code. Works all the same. Teststudent (talk) 00:24, 14 March 2012 (UTC)

Use table recentchanges

Table page is expensive, use recentchanges instead. Subfader (talk) 09:11, 12 September 2012 (UTC)

What if it's a wiki that sets a high value for $wgRCMaxAge, or it otherwise has a high ratio of recent changes to pages? Then there would be more rows in recentchanges than in page. Although I suppose we could take advantage of that new_name_timestamp index in recentchanges. Leucosticte (talk) 13:16, 12 September 2012 (UTC)

It's a possible scenario, yes. But I doubt that a wiki with few articles has much contribution action.

It's not about which table is faster. The point is that an ordered query on the page table is def an expensive query.

While writing I realize that using recentchanges could lead to no new page being listed when there is contribution action but no new pages within $wgRCMaxAge.

I don't care much since I don't use this extension tho. Subfader (talk) 13:55, 13 September 2012 (UTC)

The original RecentPages deliberately used the page table as it was designed to be used in cases where Wiki was being used more as low volume CMS than a wiki.

I note that a recent contributor has rewritten the extension and not changed the author credits. I don't mind people rewriting my code - it is after all what GPL is all about - but the code is completely different now, so it is pretty much a separate extension, and I'd prefer my name to be dropped from the credits in that case QuantumTiger (talk) 16:31, 9 October 2012 (UTC)

Include RecentPages in Main Page

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. 213.47.219.66 12:26, 23 January 2013 (UTC)

I've had the same problem, I'd be grateful if this was fixed soon. 2.221.94.217 02:11, 29 January 2013 (UTC)

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... 79.160.163.66 18:36, 4 March 2013 (UTC)

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. 110.32.139.168 17:08, 17 March 2013 (UTC)

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. 69.204.243.73 20:36, 20 January 2014 (UTC)

So all you see is <recent />, or is it blank? If you provide a URL, it would be helpful. Thanks. Leucosticte (talk) 21:44, 20 January 2014 (UTC)

hi, I see a blank page

http://asagezi.com/

thanks 69.204.243.73 19:24, 22 January 2014 (UTC)

Please upgrade to the latest version; there have been some recent bugfixes. Thanks. Leucosticte (talk) 21:41, 22 January 2014 (UTC)

i updated the files, still can't see anything. 69.204.243.73 00:06, 23 January 2014 (UTC)

All your pages were below the minimum length of 600 characters, apparently. Leucosticte (talk) 04:13, 23 January 2014 (UTC)

Is it possible to make a list of recent added by some author?

Could you please tell me if it is possible! Thx Fokebox (talk) 07:29, 19 November 2013 (UTC)

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. Leucosticte (talk) 14:03, 19 November 2013 (UTC)

Download link doesn't work

No such extension "RecentPages"

http://www.mediawiki.org/wiki/Special:ExtensionDistributor/RecentPages 69.204.243.73 22:14, 17 January 2014 (UTC)

Amended. Just copy over the code you find on the page. [[kgh]] (talk) 22:30, 17 January 2014 (UTC)

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. Leucosticte (talk) 22:35, 17 January 2014 (UTC)

Well, not even this extensions page does it though it theoretically could. Basically it is a matter of taste. [[kgh]] (talk) 22:39, 17 January 2014 (UTC)

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. [[kgh]] (talk) 22:43, 17 January 2014 (UTC)

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. Leucosticte (talk) 00:06, 18 January 2014 (UTC)

Using this template will indeed be a solution. [[kgh]] (talk) 15:14, 18 January 2014 (UTC)

thanks for the explanations! 69.204.243.73 00:26, 19 January 2014 (UTC)

Database inefficiencies

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. Leucosticte (talk) 15:59, 18 January 2014 (UTC)

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. Leucosticte (talk) 04:41, 19 January 2014 (UTC)

Okay, got that all fixed too now. On to BedellPenDragon! Another day. Leucosticte (talk) 03:53, 20 January 2014 (UTC)

$wgRecentPagesDefaultMinimumLength

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. Leucosticte (talk) 04:08, 23 January 2014 (UTC)

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. [[kgh]] (talk) 09:22, 23 January 2014 (UTC)

300 characters ought to do it. Leucosticte (talk) 18:15, 23 January 2014 (UTC)

Eureka! It worked :) [[kgh]] (talk) 18:22, 23 January 2014 (UTC)

Cool, thanks. Leucosticte (talk) 21:17, 23 January 2014 (UTC)

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. Leucosticte (talk) 07:03, 5 February 2014 (UTC)

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. [[kgh]] (talk) 08:46, 5 February 2014 (UTC)

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. Leucosticte (talk) 08:58, 5 February 2014 (UTC)

More optimization to do...sigh

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. Leucosticte (talk) 04:12, 23 January 2014 (UTC)

Excluding a category

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. Leucosticte (talk) 01:37, 30 April 2014 (UTC)

Exclude PAGENAME from Random

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! Evilninja (talk) 09:45, 10 May 2015 (UTC)

User::getSkin was deprecated in MediaWiki 1.18

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.

Backtrace:

• RecentPages.php line 79 calls User->getSkin()
• - line - calls RecentPages::showRecentPages()

Kc5vcx (talk) 18:00, 28 November 2015 (UTC)

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 Luca Mauri (talk) 14:14, 20 August 2016 (UTC)