In contrast to "Newest Pages", "Oldest Pages",
http://abj.jidanni.org/index.php?title=Special:AncientPages&limit=500&offset=0
looks great, but is in the opposite order.

One would think adding a parameter to reverse the order would do, but then it would be tough to put into the sidebar etc. like I do.

Note that this is all that is needed in order to use MediaWiki as a
simple one person blog, without needing extensions or resorting to
WordPress. OK, I could try a new
Special:AncientPages&order=reverse or
Special:NewPages&notes=off .

I also got fed with those useless comments before, so you can easily turn them off with $wgUseAutomaticEditSummaries = false; Is that enough?

(In reply to comment #3)
Sorry. $wgUseAutomaticEditSummaries apparently only affects creation of
new items, but does nothing to clean them up for current items.

Furthermore, why should they be cleaned up? They look great in
RecentChanges.

All I'm saying is give me a way not to display them on Special:NewPages.
A way that one can link neatly from the sidebar too.

How about .page-Special_NewPages span.comment { display: none; } then?

(In reply to comment #5)
Checkmate, as my principal user uses emacs-w3m to browser the site: a text browser, so such stylesheet tricks won't help. (That he is me is besides the point.)

(In reply to comment #0)

How can one keep Special:NewPages a tidy list, when it is getting full
of that "Created page with ..." clutter, as you can see from the URL
above.

By putting edit summaries in when you create pages, These are useful (even the "created page with" ones) which is why we can't just pull them out so to that extent without creating a configuration variable to handle it, CSS is the best way to do it.

(In reply to comment #7)
CSS is totally the wrong approach. You are violating Accessibility 101.

Please add a variable one can put in the URL to turn them off, for any
special page that uses them.

Also please add a variable to AcientPages to get reversed order.

Note that I plan to link these from the sidebar so I hope {{fullurl:}}
works there, in order to take advantage of these new variables. Thanks.

(In reply to comment #8)

Please add a variable one can put in the URL to turn them off, for any
special page that uses them.

Also please add a variable to AcientPages to get reversed order.

This is not sane either. We don't want to add config variables for every use case in the universe, we have extensions for that.

Well you have one page in the right order, but clogged with comments. (Special:NewPages)
You have another page clean of comments, but in the opposite order. (Special:AncientPages)
They are called "New pages" and "Oldest pages" respectively there on Special:SpecialPages.
You don't know how frustrating it is.

I don't want to use an extension !!

The former shows new pages on a wiki, which would be useful to say, fight spam where as the latter shows old unedited pages which is why it doesn't really need comments, As well New Pages shows the full contrib compared to Ancient Pages where this data might be not as useful which is why it doesn't have block buttons and such.

(edit conflict)
These pages have absolutely different purposes:

• AncientPages is for keeping track of pages that may need in update. Edit

summary is absolutely not needed here.

• However, NewPages is intended for countervandalism and displaying edit

summaries here helps to triage the new arrivals quickly.

I don't want to use an extension !!

And we don't want to add a feature in which only one person is interested.

With an (straight, uncluttered) index of newest pages, MediaWiki is
perfect for announcement boards and small blogs.

No need for one of the many blog extensions.
No need for WordPress.

All that is needed is a (clean) index of new pages, transcludable into
the MainPage would even be better.

I've been running my mom's blog there in the URL for several years
that way, and it has been perfect -- until recently, as you see in the
URL. (Disclaimer: some of the older pages were imported.)

• Bug 38197 has been marked as a duplicate of this bug. ***