Page MenuHomePhabricator

Caching issues with inline queries (1.7.1)
Closed, DeclinedPublic


Author: dbu

I have pages with {{ask}} inline queries in my semantik mediawiki. I add new
articles with semantic properties that should be found by the query. But the
other pages stay unchanged until edited (that is: click edit and then save,
changing nothing but causing the cache to be invalidated).

Maybe bug 7998 has
something to do with this...

My workaround is to run a cronjob each night:
/usr/bin/touch /var/www/LocalSettings.php
When the config file is newer than the cache, the page is regenerated...

Version: unspecified
Severity: normal
OS: Linux
Platform: PC



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:36 PM
bzimport set Reference to bz9738.

Re-assign to extension developer for triage/comments.

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

mitchell_neill wrote:

Okay, so this issue was reported a long time ago. Is it going to make it onto the roadmap?
Can the MW call in the MagicNoCache extension not easily be added to the Form save?

I have a feeling this is being sidelined because it is perceived as difficult. I can't stress enough how important this is. SMW has got to a stage where it is an fantastically valuable and useful tool. The functionality has got to an amazing level. Perhaps performance should now be on the agenda?

We have discussed this issue at the SMW Camp in Karlsruhe: the outcome was that it is probably doable, and that it is more or less clear how to approach the issue, but that we currently do not have a developer to start this project (because this is what it is -- you cannot solve this problem by some small changes). This may change (we are actively trying to find a solution), but it does not make sense to put it on any roadmap as long as we know that no one will do it anyway.

I am still confused why Semantic Forms are mentioned here. We are not directly involved in developing SF: if you want SF to change, then you need to post a bug/feature request for this component. But as I said, I don't think that caching should be a concern to SF since it is just as relevant when editing a page without forms.

Also, I would like to stress that this is not a performance issue as such. The performance problem you mention is caused by the workaround that you use, and is not part of SMW. Turning off the cache will of course decrease performance, but this is not something that SMW forces you to do. The problem of SMW is that cached pages may be based on outdated information and are not updated automatically. Yet we run many sites, some of which with quite critical performance requirements (see e.g., and we never turn off the cache in such cases. I am not saying that it is generally acceptable to have outdated pages in the cache, but it is certainly preferable to disabling the cache in a performance-critical environment.

mitchell_neill wrote:


Thanks a lot for your comments. The reason I mention SF is because I believe a simple workaround could be placed into the SF save functionality to purge the cache. The inline query would then pull the updated or new data. Most people populate SMW using SF, so this seemed like an ideal solution.


pboyd04 wrote:

Any update on this DF? This is a feature that I think is pretty desperately needed. If you have an approach in mind could you detail it so that someone with some spare cycles might take it on?

@mkroetzsch this is the oldest task assigned to you. There hasn't been any feedback from you in the past five years. I wonder if the problem reported here is still applicable, relevant?

Aklapper changed the task status from Open to Stalled.Dec 29 2014, 12:26 AM
Aklapper subscribed.
Qgil lowered the priority of this task from Medium to Lowest.
Qgil set Security to None.

The Semantic MediaWiki developers requested in to move their task tracking to and to close remaining tasks in Wikimedia Phabricator. If you still face the problem reported in this task in a supported version of SMW, please feel free to transfer your report to . We are sorry for the inconvenience.