Topic on Project:Support desk

Hi, could someone help with a problem with time and dates please?
I have created a number of "On this day" pages, with each one having a title with the format Month space Date, eg, "May 27", "June 1" etc.

I then added the line {{#ifexist:{{#time: F j}} | *[[{{#time: F j}} | On {{#time: F j}} in SVR history]] }} This checks to see if a page with today's date exists. If it does, it creates the link and adds it to a bulleted list, if not, it returns a blank. This worked fine when logged in, but always defaulted to the date of the last page edit when not logged in, presumably because the parser function takes "the time the page was last rendered into HTML."

I changed the line to {{#ifexist:{{CURRENTMONTHNAME}} {{CURRENTDAY}} | *[[{{CURRENTMONTHNAME}} {{CURRENTDAY}} | On {{CURRENTMONTHNAME}} {{CURRENTDAY}} in SVR history]] }} thinking this would force it to read the current date, but it's exactly the same. I've tried ...title=Main_Page&action=purge and that didn't fix it. It works perfectly when logged in, but as soon as I log out, it reverts back to the date of the last page edit.

Is there a way of fixing this please? It's on the front page and aimed at visitors who will probably not be logged in when they see it, so I could do with having it working properly. It's at www.svrwiki.com if you want to take a look.

Thanks in advance.

Graham

You can use purgeList.php in a cron job to be executed once a day for the pages you want to purge. I don't think there's another solution.

Thanks, I looked at purgeList and that seems to rely on using a squid, which we don't. Extension:External Data linked to http://www.currenttimestamp.com/ might be a way of doing it if it was possible for Mediawiki to read the date. Another idea was to create a Bot that automatically updates the page every day at 00:01. All these are beyond my ability at the moment. Are any of them worth persevering with? There are various Mediawiki calendar or similar extensions out there. Do they all use #time: and have this same problem, or is there one that works for users who are not logged in?

purgeList.php also purges the MediaWiki parser cache if you pass the --purge parameter.

Thanks again. I tried purgeList.php and it's not much of a manual. With no proper explanation of how to use it, I tried everything I could think of and found it either did nothing or crashed the site.
Anyway, I think I've found a way round it. Creating an internal link as an external link that looks like an internal link seems to force the wiki to use the real current time to create that link. Like this

{{#ifexist:{{#time:F j|now }} | *On <span class="plainlinks">[http://www.svrwiki.com/{{#time:F_j|now}} {{#time: F j|now}} in SVR history]</span>}}

I'm not sure the "now" is really needed, but my connection is so slow tonight that it's taking several minutes every time I log in, log out, preview, or save, so as it's working at last, I left it in. The underscore is needed though for an external link. As an internal link it worked OK without it.

You can see the site as anon without logging out by using the private browsing option of your browser. The external link shouldn't make a difference. Maybe the use of "now" is forcing the page to not be cached?

No, I tried that first, thinking that if it was going to display 0 seconds offset from 'now', that it would look up the real 'now', but it didn't work.

It was while right clicking and selecting "Inspect" for various elements that I noticed times and dynamic links to internal pages based on time were coded directly in to the HTML, while external links were created live.

One problem was that I've set the wiki to open internal links in the same tab and external links in a new tab. By using a full url for an internal link, it was opening in a new tab. Once it has created an external link using #time though, it sets the #time correctly for the rest of the page, so I got round it by creating an external link that is just a full stop, hidden at the bottom of the page, and an internal link, that now works, in the normal place.

This {{#ifexist:{{#time:F j|now }} | *[[{{#time:F_j|now}} | On {{#time: F j|now}} in SVR history]]}} won't work on its own.

As long as this {{#ifexist:{{#time:F j|now }} | <span class="plainlinks">[http://www.svrwiki.com/{{#time:F_j|now}} .]</span> }} is somewhere on the page, it will.

I'm surprised this problem hasn't come up before and been solved properly. Surely most people just look at a wiki to get information, they don't bother logging in unless they are going to edit it. I know what I've done is a bit of a bodge, but it works, so hopefully it will be of use to someone else.

You seem to be using an extension for such external links, because external links are generated server-side and sent with all the HTML, not "created live".

The problem is not new, Help:Magic words already warns it may give incorrect results because of the cache.

Maybe a simple fix is using Extension:MagicNoCache.

Thanks, I didn't know about that extension, maybe that would have been an easier way to do it.

I don't know if disabling the cache on the Main Page would slow it down noticeably. If so, maybe creating a page titled "Today" with the content __NOCACHE__ <includeonly>{{#time:F j}}</includeonly>, then using {{:Today}} instead of {{#time:F j}} on the Main Page would speed it up again. I suppose that would depend on whether #time got calculated before or after the transclusion.
It's working now, but I might try that one anyway, just to get rid of that full stop.

__NOCACHE__ is going to leak to the main page making it not cacheable. In fact, if the main page is cached you'll have exactly the same problem, because the cached main page won't be updated (which is what's happening now)

Thanks again. __NOCACHE__ was the answer.
The Main page has always been slow to load, and I was concerned that disabling the cache would slow it down even more. It turns out it was a map on the Main Page calling several icons from Wikimedia Commons that was slowing it down. Duplicating the icons locally got the page loading a lot quicker and disabling the cache made no noticeable difference.
Having a random image on the test Main Page, but not on the real Main Page didn't help, as that refreshed the page every time it was viewed, effectively disabling the cache, making me think I'd solved the problem when I hadn't.