Violet

In case anyone else has this problem, I just wanted to update with a workaround. Simply turn off the update checking at login. In the admin panel, it's Modules -> Configure -> ProcesswireUpgradeCheck Now I have blazingly fast logins again! Obviously, to keep on top of PW updates, you will have to check for updates every so often ( setup -> Upgrades ) I think my shared hosting provider might have some ModSecurity rule that is inadvertently being triggered, or a slow DNS lookup, or something like that. But if you're on shared hosting like I am, you might never be able to find the problem, and even if you found it, the host might not be willing to make any changes. I have updated the title to show that there's a workaround.

Thank you @BitPoetfor helping untangle this tangled mess. Glad the SchedulePages message is normal. To follow up on your suggestions, I looked at the server logs, although that unfortunately only gives me incoming connections. I also tried loading the Upgrades page with F12 on the browser to see what was happening. Both the server logs (not shown here for the sake of simplicity) and the browser F12 (pic below) show the same thing, which is that the main request takes ages, but everything else seems fine: You will notice that there is a warning and a log entry flagged on the pic above, but if we look at these they don't seem like anything important (although that's beyond me): Since I'm on a shared server, I can see my own server logs of incoming requests but that's it. I can't see where outgoing http(s) requests are going. I think you must be right that there is some DNS lookup problem or an issue with certain types of outgoing connections at my web host, but it looks like it won't be possible for me to track that down. I'm puzzled because I don't know why this suddenly started yesterday - I hadn't made any changes just before I logged in that morning, no changes to my templates either. In other words I don't know why this problem just cropped up out of the blue yesterday. (I think it was yesterday - it may have been the day before, but I think yesterday). My standard outgoing links (e.g. front-facing pages on my blog site that link to an external site) are working fine and seem to be resolving normally and at a normal speed. Thank you, it helped to have an idea what to look at. I think at this point I may have to just accept the lengthy login time, unless you or anyone else can think of anything else that I should look at. Thank you for your time on this problem, it is much appreciated.

Hello, I will describe the problem(s) I'm seeing, not sure if it's related or 2 separate problems, and below I have listed what I have tried so far. I'd love it if someone would please point me towards a possible solution or things to try. As background, these are PW sites that have been running for awhile. PW version is 3.0.229 The 2 problems Recently, over the past day or so, I noticed that both of my PW sites were very slow to log in, I thought it was hanging but it did eventually log in. I initially thought it was a problem with my host, but once I'm in everything is fine and goes fast so I don't think it's my host. My memory usage at my host is extremely low so I'm nowhere near using my allocation, so I really don't think it's the host (although can't exclude the possibility). On one of my sites, in admin panel when I go to setup -> upgrades, it says core up to date, it also lists schedulepages (see pic below), but when I click on schedulepages it says "Error reported by web service: That module is not currently tracked by the modules directory" (see other pic below). Only 1 of my sites has problem 2 (schedulepages upgrade checking error) - the other site does not have the schedulepages module, but still has the first problem of being very slow to log in. upgrade list pic: error message pic: What I have tried refresh modules (does not resolve either problem) put debug true, no errors seem to be reported on either site, other than informing me that debug mode is on when I log in checked logs from inside pw admin area (setup -> logs) Nothing in the error logs is more recent than 3 months ago. The other logs don't have anything more recent than 2 months ago. Out of interest, the modules log's most recent entry was 2 months ago, (with url question mark) Compiled file: /site/modules/SchedulePages/SchedulePages.module I tried navigating within my admin section doing different things. On both sites, when I go to setup->upgrades, it has the problem of taking a really long time to load (even on the site that doesn't have the schedulepages module). But anything else I do in the admin panel on both sites is really fast (e.g. edit page, setup-> fields, etc etc). I also noticed that it seems to have stopped telling me upon login whether my PW core is up to date (even though my Upgrades Checker is set to Yes for "check for upgrades on superuser login?") Thank you for anything that anyone can suggest to point me in the right direction. The sites are certainly usable from both the frontend and backend - but the slowness of login is concerning.

Oh thank you for this explanation. Much appreciated!

Thank you for this idea! This sounds neat, definitely will be checking out New Relic. I hadn't heard of it before, so this is certainly helpful information. Thank you for your valuable suggestion of using timestamps via the Page Hit Counter module. At first I thought this might take more customizing/coding than I'd be comfortable with, but then I saw on the Page Hit Counter module page it says: ... so it seems a lot more flexible than I first thought! It's not just a "look at stats in the admin panel" thing, it's way more than that. I can query actual numbers of hits for a particular page, sort pages by number of hits, etc.

Overall, I'm trying to make the behavior of my PW sites dependent on traffic amount, where in high traffic situations I want slightly different behavior, which I have an implementation in mind for - my only problem is how to approximately quantify traffic rate from within my template code. Any ideas? As background, I'm trying to do something vaguely similar (but only vaguely!) to Ryan Cramer's post of how he drove around a DDOS attack - you don't need to read the link if you're busy - I'm just trying to show where I'm coming from in case anyone wants the background. I already have a solution for page requests for commonly requested non-existent pages like wp-admin (return server 404's instead of letting PW handle them). So it's only the level of traffic to my legitimate pages that I'd like to get a feel for. I'd ideally I'd like to know things like rate of SQL queries or the rate of bandwidth - is there a way to get an idea of that from within a template? I already know about the PHP function sys_getloadavg() from Ryan Cramer's post linked above. That would be my default measure if there's nothing better I could use. The only downside is that sys_getloadavg() could be high for reasons other than either DDOS or legitimate traffic. For example, when my server is doing auto-backups on cron or doing other automated tasks, I'm assuming that it could contribute to a higher load average for reasons other than traffic. I don't plan to give up any of these essential tasks, so is there a way I can get an idea of traffic that is requesting normal/existing pages? In case it has a bearing, only 1 page template would be affected by this. Thanks for any help anyone can provide. Even if you don't have a specific solution to this exact question, I'd love to hear any comments/input that you might have surrounding this overall topic.

Wow! It gets even better! ? Thank you Ryan for the detail, including an example of actual code (I would never have figured that out on my own). I will definitely be implementing this so I can add my affiliate disclosures at the click of a button! There will no longer be the need to retype the same sentence of text at the top of my articles, or even to copy and paste it... instead I will be able to add it at the click of a button! That is wonderful.

Wow! Thank you Ryan! ? I read the post and am already drooling over the upcoming editor and its features. If this seems a bit extreme, I should mention that what prompted me to move to ProcessWire (from Wordpress) was the switch to the Gutenberg editor in Wordpress - it was a definite downgrade upon their previous editor, it simply wouldn't let me type my content in as quickly. After moving to ProcessWire I quickly reaped the rewards of its editor and in addition, all the other advantageous features of ProcessWire. As a blogger who owns multiple sites I am constantly writing articles and therefore the choice of editor is extremely important to me. I am crying tears of joy over the stickybars feature in the new editor ? No more need for scrolling up just to get to the editor buttons again, yay!! I was also thrilled to see that we'll still be able to get spellcheck and wordcount on the new text editor - essential features. And retaining the ability to edit the text as source code is a must-have for those of us who are including affiliate links or ad code in our articles, thank you for ensuring that continues to be provided. The configurability of everything via toolbars and plugins looks great. I'm excited that we can add an undo button on the toolbar (maybe we could do that on the current editor too but if so I never figured it out ?) Thank you for the thorough explanation and all the screenshots, it's very helpful to see what we will be getting. I am very excited about the new editor and am looking forward to using it!

Wow thank you! Everyone helped a lot. This was great advice. Thanks to all of you, the problem is now solved. I was checking each of the things that all of you said, and this was very valuable because in some cases I uncovered some errors or problems that were unrelated to this issue but that needed to be fixed, so I fixed those as I went. So checking php logs, admin panel logs, and using debug = true in the config file turned out to be extremely helpful things to do. My site is simple, with only 1 extra module installed (the PW updating system), and no libraries or other code. So there were a limited number of places where the problem had to be, and I went carefully through the list of suggestions that all of you gave. The solution In the end, it was @pwiredthat came up with the correct idea - my template had an include for a non-existent file! I didn't notice it before and I had no idea it was non-existent, but when I looked carefully in each line for includes, sure enough there was no file of that name. Thank you pwired! And thank you also @Gideon Soand @flydev - your suggestions helped me identify other errors or problems with my site that I have now fixed. Thank you both! I was a bit surprised that in php 8.1 the include resulted in a 404 not found page, yet in php 8.0 the page was displayed properly (the bad include was ignored). The include was a little way down the rendering of the page, so I expected instead of 404 I would have gotten the top of my site rendering at least (everything above the include, such as the top menu etc). But I don't know much about the different versions of php so maybe 8.1 has a different way of dealing with this. Certainly I should have never written code with an include to a non-existent file! ? It was not at all intentional, I removed the file of the include at some point but forgot to delete all references to it in the template file. I will update the title to mark this problem as solved. Thanks again everyone! I couldn't have done it without you, I didn't even know where to start.

I originally set up my ProcessWire site under php 7.4 and then moved to php 8.0 and then to php 8.1 at my web host. However, one set of pages with a particular template refuses to display under php 8.1, instead giving a 404 page not found. It's the standard 404 that I get if the page does not exist. But the template file does exist! And the pages are published! I can work around the problem by taking the php version back down to 8.0 (7.4 also works). But if I bring it back up to 8.1, those pages are not able to be displayed. Does anyone have any suggestions of what I should first start looking at to troubleshoot this issue? What I have tried so far: I tried to duplicate the template under another name (and yes it did produce a template file in my templates folder with the new name as expected) and I switched one of the problem pages over to the newly duplicated template, but the 404 still persisted under php 8.1. I have another template that is very similar to the one whose pages won't display, but the similar one works just fine in all php versions. I can't understand why one template would work but a similar one gives a 404 (in php 8.1). They all work fine in php 8.0 and 7.4 I'm not too concerned for the short term as my site works fine with php 8.0, but I'd like to do something about it because I do eventually want my site to work with php 8.1. I realize this is a pretty large/open question, but I would love it if anyone can give me any ideas of where I could start looking to fix this. I would love to be pointed in the right direction.

Thank you @TheMick- it looks like I did miss that. It sounds like it would work, although I admit it's a bit beyond me - I'm not an experienced programmer. I was hoping to avoid writing functions. I can't remember what I did in the end on my particular project - I think I just decided to use a reasonable number of images that would look OK on 1 page and didn't bother paginating them. If I need to go back to that I will definitely take another careful look at the solution you mentioned and implement it for my situation. Thank you for bringing this to my attention, as other people who come across this thread will now be able to direct themselves to the solution you mentioned ? ?

Thank you, this was a huge help! I had gotten really stuck until I read this post. One tip in case it helps others: at least on 3.0.184, it isn't clear how to mark the childless new-parent page before moving the other page to it. Clicking the new parent and moving the other page still didn't work for me. Maybe I was doing something wrong. In any case, what DID work for me is to create a temporary new page (e.g. call it 'test') as a child of the new parent. Then drag and drop move the other page in there. Then trash the test page. This is a clunky solution, but it will work if all else fails.

Sorry, but can we please remove this site (https://reached.space) from the showcase? I have been running it for 3 years now, but sadly it has not done as well as some of my other sites and I haven't had as much time to devote to it as I would have liked. I have therefore had to make the difficult decision to shut it down in the next few weeks. From about 30 days from now it will no longer be running, and the domain name will no longer be in my control.

My question relates to one of my live sites. I empirically managed to solve my login issue of "This request was aborted because it appears to be forged" [details below], but I don't understand the inner workings of PW, so I don't understand the theory behind why/how I fixed it, and thus, I don't know if I've managed to inadvertently introduce a security issue/loophole. Would anyone please be willing to let me know if my change, moving forward, is likely to cause any such issues? I don't have any reason to believe I *do* have a security issue (I made my change only an hour ago) but I am hoping other users can weigh in on this. DETAILS: The problem: Yesterday I updated 2 of my sites from 3.0.165 to 3.0.184 from within PW admin page, using the upgrade module - this is the way I've always done it. Immediately afterword, both sites appeared to be working fine from front-end and admin, and I even wrote and saved an (unpublished) article in what would become the problem site, then I logged out. Unfortunately, this morning, although both sites were fine from front-end, I could not log into the admin area of the problem site, getting "This request was aborted because it appears to be forged". The other site was fine and I could log into that. The solution: Since both my sites were on the same web host and had a lot of similarities, this was actually incredibly helpful as it let me narrow down where the issue might be. I won't go into everything that *didn't* work (although I noted it all down at the time so I have it if anyone asks for it), EXCEPT for 1 thing that might turn out to be relevant: the "good" site had site/config.php perms of 0644, and the "problem" site had perms of 0400. I tried changing the problem site perms to 0644 but that didn't fix the issue, so then I changed it to 0600 so I could at least write to it (e.g. to change $debug to true, etc). By comparing the contents of the 2 site/config.php files, I was able to narrow down the difference (this was AFTER ruling out a bunch of other things that I won't go into here). The difference is that the problem site had these extra lines which were absent in the good site: $config->sessionAllow = function($session) { // if there is a session cookie, a session is likely already in use so keep it going if($session->hasCookie()) return true; // if URL is an admin URL, allow session if(strpos($_SERVER['REQUEST_URI'], $session->config->urls->admin) === 0) return true; // otherwise disallow session return false; }; I commented out those lines and afterwards everything worked and I could log back into the admin area of the problem site. So, problem fixed, yay!! But - WHY were those lines there in the first place? They must have been from an older version of PW that I was running in the past. So they must have been doing SOMETHING, so have I caused a security issue in deleting them? Any advice you have about that would be very helpful. And also, was it therefore a bad idea to have my site/config.php perms on 0400? They're on 0600 right now on that site in case future PW upgrades need to change config.php. I thought 0400 was 'good' based on https://processwire.com/docs/security/file-permissions/#potential-permissions-for-site-config.php but perhaps I should have done 0600. Thank you for reading this and for any insight you can provide.

Perfect thank you @Soma ! I had the exact same problem so I came across this thread and I used your code. It worked beautifully.