Closed slavkoja closed 3 years ago
Hello,
I managed to reproduce your issue through CLI. The underlying problem is that webtrees explicitly boots only the "current theme" (code in ModuleService). The rural theme not being the "current theme", it is not booted, and therefore the view namespace is not loaded, triggering the error.
To be able to query this URL then requires to set the "current theme" to the Rural one. There is unfortunately only 2 ways to do so: stored in the session, or if the theme is the default one for the site. The browser would handle the session storage itself, but by default, there is not any through the CLI. I managed to make it work by setting the Rural theme as the site default theme (Control Panel > Website preferences > Default theme). There is probably a way to set the session data through wget, but I have not look at the details.
Just to pick up on your initial test, I have an outstanding change, to be released with the next version, setting a Cache-Control
header on this request, based on the same logic as the one used for Assets. The browser should then cache it, and not request it on every single page load (which I only noticed recently).
Hi,
thanks for quick response. I understand the "default theme" and the session/cookies problem. While i do not expect that the CLI will be used often (except some tests), but IMO request must not fail with 50x anyway.
Is it possible to solve this error in the theme itself?, eg. by providing empty response with 200 (or 404?) code? Or have i to fill issue about this to webtrees? I am not PHP man, thus understanding internal structure webtrees (or its theme) is terrible task for me...
BTW, manage the cache in nginx is really simple, i finished with this snippet:
location = /webtrees/index.php {
if ($request_uri ~ "/module/_[^/]+_/(?:Asset|CustomCss)(?:\?.+)?$" ) {
expires max;
}
include fastcgi.conf;
include file/with/fastcgi/socket/path;
}
This allows site admins to choose caching time, which i consider as better approach as hardcoded value... Perhaps you an use this snippet, instead of code change.
I forget to mention, i ask to solve it in theme, because request to '/webtrees/module/_myartjaubruraltheme/Asset?asset=images%2Fheader.png&hash=1615475106' works as expected and returns 200 code.
Is it possible to solve this error in the theme itself?, eg. by providing empty response with 200 (or 404?) code? Or have i to fill issue about this to webtrees?
You are putting me in the controversial situation to choose whether the module or the software should be modified, not one we usually like to answer... :relaxed:
On that occasion, and at the risk of taking the easy approach of pushing back the issue to the core framework, I believe this is more for webtrees to handle it.
My reasoning is that by not calling the boot
method beforehand, webtrees fails to fullfil its contract with the module which is expecting to be booted. This initial contract not being fullfilled, the subsequent uses of the module are invalid, and can/will produce unexpected results.
Technically, code can be added in the theme to handle those cases, but I feel this is going against the abstraction principles in place, as I would need to either use logic pertaining to the framework (if at all possible, as the View class does not give an insight on the registered namespaces), or perform checks over and over just to make sure that what was expected has actually happened. This raises as well the question of how the module should handle those cases without taking decisions that go beyond its scope within the context of the request: should it stop the request? return something? ignore and continue the code execution?...
Again, this is only my view as a module developer, and Greg may have a different approach to it, and argue that the module should be more robust to those cases, but that is probably more a discussion to have on the webtrees forum or Github.
As a warning, given the heavy changes still in progress in the core framework, I am not sure there will be a lot of appetite to address a use case rather on the edge, but it can help clarify what should be done with non-booted theme: they should probably be considered disabled for the purpose of the request, and a seemingly easy fix could be added to the ModuleAction
request handler in that direction to return a HTTP 404 like a disabled module.
i ask to solve it in theme, because request to '/webtrees/module/_myartjaubruraltheme\/Asset?asset=images%2Fheader.png&hash=1615475106' works as expected and returns 200 code
The Asset logic is already handled in the webtrees framework, and does not rely on the module being booted, so it would work (arguably, the getAssetAction
could be neutralised as well following the logic just above for non-current themes...).
For information, the faulty behaviour can be reproduced on at least the popular JustLight theme as well, if you request the /module/_webtrees-theme-justlight-main_/Stylesheet
URL, for exactly the same reasons.
BTW, manage the cache in nginx is really simple Perhaps you can use this snippet, instead of code change.
This indeed achieves the same result, but the module does not interact with the underlying webserver, and I cannot expect all users to know how to setup Apache/IIS/Nginx rules (and some shared hosts may not allow it at all). Setting the Cache-Control header in the code can still be overwritten by the webserver rules, so the two approaches are not mutually exclusive, and I prefer to include a default cache behaviour.
I am sorry for inconvenience, it was not intended, i ask you, because nobody know your code better than you ;-)
From your description, especially that it is reproducible with other theme too, i agree with you, that it is a webtrees issue and i will fill it there after i summarize my English to describe it properly. If or when it will be fixed, is on webtrees's devs decision, but when it will not be filled, is possible that it never will be solved...
BTW, caching headers noticeable shorten (speed up) page loads, especially on my tablet...
Hi,
i play with your 2.0.12 theme with or webtrees 2.0.13 and assets caching in nginx. While i test my rules with
wget
(to see full repsonse), i found that the request to/webtrees/module/_myartjaub_ruraltheme_/CustomCss?v=2.0.12-v.1
fails with 500 code. The error doesn't happen in browser, only viawget
. The error snippet is:I really do not know to decide, if it is error in your theme, webtrees or even another module, but it happens on every request. Can you please look into it?