matjazp

Yeah, that's the point here. I don't have enough knowledge about the boot process and all this (I'm just a hobby user). What I would be interested in if someone with ProCache would explain how it works and how ProCache knows all that details if PW (or even) php isn't touched at all? I assume it takes all of this into an account and creates a cache file only if those conditions are met? I simply ignore all POST requests, all GET requests (other than paginations - I didn't test with segments, hmm...), ignoring logged users. I wanted to be sure that I don't echo something I shouldn't so this was the easiest and possibly the safest way to go... I mentioned that to Ryan in PM (he contacted me in regards to recent hacking attempts), but he ignored my idea. Or perhaps he didn't read to the end of my message? Or he likes my approach but has no time to implement it (I just asked for a way to include some script before PW starts)? Or maybe he is working on it??? I wouldn't count on him, he has more important things to do, I guess, like fixing issues that bothers a lot of users for quite some time or even accepting some of the 278 feature requests :-) I guess I won't have time for programming for at least for a week or two (you know, covid-19), will see. I started this as addon to AIOM, then separated it, then merged it again with AIOM+ as template caching might interfere with the HTML minimizing option in AIOM+ and decided it would be best if I have control in one module.

The inefficiency I noticed was that the render time (I just use Chrome console with disabled caching, monitoring the Time column) with enabled or disabled template cache was almost the same. I used just a simple template file with the echo "foo"; in it. Then I read about ProCache and learned that it delivers cached pages directly from the disk without even touching the php. I tried this approach on Windows with IIS but the URL rewrite module complained about some caching issues, so I ditched this approach (this is likely IIS issue). Then I tried with php echoing the file from the disk and it worked. I looked at the source code of some core files and discovered that cached pages are actually already there on the disk, but it takes time before PW reaches them: it has to go through the boot process, load/include all the modules/files, etc. and that process takes time. So the module creates its own AIOM+ cache files based on page URLs/names with information about the actual page cache file and its expiration. I check this AIOM+ cache file, load the content and echo it. That process takes between 5 and 10 ms on my computer, while "full" load time is between 300 and 350 ms, and with cache like 300-320 ms. I'm not sure this is a good way to go. My biggest concern is if this is safe? I assume ProCache does it similarly?

I updated my forked version of AIOM+ to 4.0.0 https://github.com/matjazpotocnik/ProcessWire-AIOM-All-In-One-Minify It adds "AIOM+ template caching" :-) My tests shows noticeable improvements in render times, dropping from like 300 ms (on localhost) to 10 ms. I guess ProCache would be even faster (don't have it, can't test). If anyone wanna try this early alpha version, please read README.md (must read).

I know it was a bot and I know the originating IP. I blocked IP and agent string and then it stopped. Why/how it happened is unknown. That is, I know it was GET and not POST request, I know the querystring but I wasn't able to duplicate the error.

This also came to my mind. Although it could be considered as unexpected result even if you don't have includes and the page is not updated when you update the template file... I'm testing on localhost, SSD disk, for simple echo "foo" in my template file it takes cca 300 ms in Chrome network panel (Chrome caching disabled).

As guest in incognito.

I am using opcache built in php on windows/IIS and it helps a lot. I don't have a problem with the speed of my sites, I'm just brainstorming- wondering why caching doesn't help that much as I expected. But I'm working on my own caching solution and results so far are very good.

@MoritzLostThanks for confirming that. I guess there must be some reason for that? As PageRender could take this into an account. @draganThanks for the hint. What is the difference between the MarkupCache module and https://processwire.com/api/ref/wire-cache/? Still, this is something developer should do, it's not on/off solution (and to be fair, template cache would probably also not be good solution for just every template).

I've set up the template cashing on the Cashing tab, like 3600 seconds, for Guests only. When I access the page I can see that the cache file is created at /site/assets/cache/Page/ folder. On the next access of that page the content is served from the cache. What I observed is that the caching isn't really effective as my page render time is almost the same. I guess that if the page would be "heavier" the difference would be more significant. It looks like PW takes it's time to boot and there is where most of the time go. What are your observations? Also, when you edit the corresponding template file (aka basic-page.php) and made some changes, those changes are not reflected in the output until the cache expires or you edit and save the page with that template in admin. Can anyone confirm?

My site is under "attack", this are the errors: User: ? Error: Exception: SQLSTATE[42000]: Syntax error or access violation: 1059 Identifier name '/../boot.ini........................................................................................' is too long (in \wire\core\WireDatabasePDO.php line 499) User: ? Error: Exception: SQLSTATE[42000]: Syntax error or access violation: 1059 Identifier name '/../../../../../windows/win.ini.....................................................................' is too long (in \wire\core\WireDatabasePDO.php line 499) What to check? How to react? It's my first time :-)

$config->webpOptions = array( 'quality' => 90, // Quality setting of 1-100 where higher is better but bigger 'useSrcExt' => false, // Use source file extension in webp filename? (file.jpg.webp rather than file.webp) 'useSrcUrlOnSize' => true, // Fallback to source file URL when webp file is larger than source? 'useSrcUrlOnFail' => true, // Fallback to source file URL when webp file fails for some reason? ); Set 'useSrcUrlOnSize' to false?

@dragan thank you. $wire->addHookAfter('ProcessLogger::execute', function(HookEvent $event) { $event->return .= '<script>jQuery(document).ready(function($){$("#AdminDataTable1").trigger("sorton",[[[1,1]]]);});</script>'; });

This is certainly something Ryan would easililly implement as you suggested, but you know that he almost never accepts PRs. This is not an issue but rather feature request, but there are already so many of them ... I was playing with simulating click() on MODIFIED column but failed, my js/jquery knowledge is a bit limited :-)

When you view log files in the admin (Setup->Logs), they are sorted by name. I would like them initially sorted by date, newest to oldest. WireLog::getLogs() method support that with $sortNewest parameter set to true but there is no option to pass that parameter to ProcessLogger::___execute() method. I could hook before and replace the whole ProcessLogger::___execute() but don't like that. Any other option?

Perhaps go with "Število slik: xx" xx can be any number and works in English too.

As the module is quite new, renaming the module in this stage wouldn't be a bad idea? Perhaps in combination with "custom element" for uniqueness as Macrura said...

Found what was going on and created the issue https://github.com/processwire/processwire-issues/issues/1076 I would still be happy if someone else coud test it...

@dragan maybe I wasn't clear: I'm not developing a module and I'm not trying to delete a module from any other module or template or any other script. I just want to delete the module(s) using PW admin interface. It's actually public function ___delete($class) that fails...

I have this folder structure in my modules folder: C:/inetpub/wwwroot/site/modules/Aa |-Aa.module |-folder B- |-folder C That is, in folder Aa there is folder B and inside is folder C. When I delete this module via modules I get an error that module Aa can't be deleted. File Aa.module is deleted, folder C is deleted, but folder B is not deleted and because of that folder A is not empty and also not deleted. The odd thing is that when I do wireRmdir("C:/inetpub/wwwroot/site/modules/A", true); in my template file, the folder is deleted as expected. Anyone willing to try? I found out that commenting the do loop in ProcessModule.module, around line 2126 makes it work!

@Haagje R. as dragan said, first setup ftp or shell access to the root of PW installation and then remove/rename install.php. I don't get it how the site was working with install.php present. Then, as Bitpoet said, replace ProcessWireUpgrade module with the new one, as this is the problem. I use PW on WIndows/IIS and not on Linux/Apache but I can help using Teamviewer. PM me if needed.

@christophengelmayerThis was a bug in PW core, but it's fixed in 3.0.150. But Ryan recommends: "it's good to have a module in the ProcessWire namespace, since module names must already be unique." So, I currently see no benefit having your own namespace and recommend you change it to ProcessWire (or have no namespace if you want your module to be compatible with PW 2).

This is now fixed in https://github.com/processwire/processwire/commit/c5417d98ad968ae1aa4b00c73304dc1b4f21c2f3 (PW 3.0.150)

Just edit your profile, it has system field admin_theme, and the error is there... It really bothers me as I don't know what could be wrong.

I found out that this warning pops up if you edit a field admin_theme (and I have admin_theme field on that template).

Would you mind sharing your code? I'm thinking that maybe a textformatter on RTE field would be better fit in some cases as generally images in header/footer are most likely already optimized? I would also be interested in how it goes in long term, what are the savings with webp comparing to optimized images. I wasn't testing with <picture> but I used this approach: $config->hasWebpSupport = (strpos($_SERVER['HTTP_ACCEPT'], 'image/webp') !== false); //this is in /site/config.php $url = $config->hasWebpSupport ? "webpUrl" : "url"; foreach($page->images as $img) { echo "<img src='{$img->$url}'> "; } But I think Horst commented that this would kill caching (don't remember exactly...). Also, some browsers don't support webp, but I wouldn't bother too much.