Violet

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.

I came up against this same issue recently, and I was able to find a solution at least for my case that did not require a module. It turned out there are 2 things going on: 1. The way the redirect is set up in .htaccess 2. Browser caching So what you would want to do is to put your redirects in section 8 of the PW .htaccess file. Do not do this, it will give the ?it= Redirect 301 /security.txt https://yourdomain.com/.well-known/security.txt Instead do it like this: RewriteRule ^security.txt/?$ $1/.well-known/security.txt [R=301,L] At this point, test it out in another browser and/or on another device because you will run into issues with browser caching where it'll seem like it's still adding the ?it= but it's just from the cache. If you don't want to try another browser or device, then clear your cache on your current browser. The browser caching issue set me back for awhile until I thought to check it on another device! At least, the above solution is what worked for me and for my use case. Besides using it for security.txt (where that page is not written in PW, I just created it manually and uploaded) I also use it when I'm redirecting a regular front-facing PW page to another, and it works there too. I just put all of those in section 8 of the .htaccess file and it works.

Thank you so much @Robin S and @Jan Romero for your detailed answers including full code, I would not have been able to come up with that on my own with my current coding ability, I only deal with my own sites and I have not figured out hooks on my own yet, so your code that I can copy and paste into my files is much appreciated. Sorry about the late reply - I had meant to get back to both of you much earlier. Likewise to your concerns, I did not want to derail this thread with my question. But to get back to the OP topic at hand, which is possible future changes for PW, specifically the admin panel, I feel that there is some relevancy for considering additional/dual sort order options built into the core. Maybe an option such as "sort children first by ..., next by ....." could be a possible feature for consideration in the PW core? This is because I feel like perhaps one thing that could have a bit of emphasis in PW is the experience for the admin. If a designer is handing over a site to an admin, the admin is the one who will be adding more and more pages to the site, and ultimately they (hopefully) will wind up with hundreds of pages of content, some of which needs to be updated more frequently than others. In this case, having the page tree displayed by sorting by 2 different options could be very helpful. For example, in my case I'd like to sort by custom field "sticky" first, and then by "date published, reverse". I'm not trying to derail this thread into my use case, but I'd like to point out the general use case of a PW page tree of hundreds of pages, of which some will be more important/significant to quickly locate than others. The use case where all pages fit on one page of the page tree should be considered as an edge case rather than a typical use case in terms of the admin UX experience. All of that said, I love the admin panel menu Find, and I love than I can narrow down to the pages I want there by selecting the combinations of templates and/or fields that are relevant. So that is a way of finding specific pages without looking manually at the many screens of page tree. Indeed, this Find menu itself can be used in combo with Jan Romero's custom "sticky" field, where any pages labelled "sticky" can be found easily. The existing Find menu as it stands is admittedly much better than any equivalents in other CMS's that I'm aware of. But I would love to see a dual way of sorting children in the admin page tree, I mean sort first by.... and next by..... To be fair, I'm not sure if that's a feature that others see as important. Site admins who have hundreds of pages may well feel the need for something like this though.

Updating on the final situation - a huge thank you to @Zekafor pinpointing the problem and getting me to the correct solution. I wound up using the solution you mentioned by @ryan in your thread you quoted. So the final code is: $flinks = new PageArray(); $flinks->setDuplicateChecking(false); $recentarticle = $pages->findOne("template=article, sort=-published"); $flinks->add($recentarticle); $flinks->import($homepage->desiredpages); $allarticles = $pages->find("template=article, sort=-published"); $allarticles->remove($recentarticle); $flinks->import($allarticles); $items_per_page = 3; $start = ($input->pageNum - 1) * $items_per_page; $flinks->setLimit($items_per_page); $flinks->setStart($start); $glinks = $flinks->slice($start, $items_per_page); foreach ($glinks as $onealink) { // ... here I display info about each item ... } echo '<a href="#afterpag" class="skip">' . $pagenavend . '</a>'; echo $flinks->renderPager(array( 'nextItemLabel' => $nexttext, 'previousItemLabel' => $prevtext, 'listMarkup' => "<ul>{out}</ul>", 'itemMarkup' => "<li class='{class}'>{out}</li>", 'linkMarkup' => "<a href='{url}'>{out}</a>", 'currentItemClass' => "active" )); I tested it with different values of $items_per_page and it all worked fine. Thank you so much! I was thrilled to get it working so quickly! I have marked the topic as solved.

Thanks @Zeka for mentioning about the start set to 0 and pointing me in the right direction. I am working my way through the thread you mentioned. I was hoping to not have to slice the array and keep track of the start point for each page etc. I wanted to just have PW handle everything automatically like it would for a simple $pages->find with a limit on it. But it looks like I will have to do something a little more complicated, according to the thread. I have been making some progress by using some of the approaches in the thread you linked thanks, I'm hoping to get to a fully workable situation eventually.

I have constructed a PageArray with pages in a specific order, as shown in this code below. I then try to apply setLimit and setStart to the PageArray to paginate it, but that doesn't seem to work. When I do that, the entire contents of the PageArray (5 items) are shown identically on both page 1 and page 2, instead of the first 3 items on page 1 and the last 2 on page 2. Where have I gone wrong with my code? $glinks = new PageArray(); $recentarticle = $pages->findOne("template=article, sort=-published"); $glinks->add($recentarticle); $glinks->import($homepage->desiredpages); $allarticles = $pages->find("template=article, sort=-published"); $allarticles->remove($recentarticle); $glinks->import($allarticles); $glinks->setLimit(3); $glinks->setStart(0); foreach ($glinks as $onealink) { // ... here I display info about each item ... } echo $glinks->renderPager(array( 'nextItemLabel' => $nexttext, 'previousItemLabel' => $prevtext, 'listMarkup' => "<ul>{out}</ul>", 'itemMarkup' => "<li class='{class}'>{out}</li>", 'linkMarkup' => "<a href='{url}'>{out}</a>", 'currentItemClass' => "active" )); The template allows page numbers, I checked it, and I've set it to page URL's requiring a trailing slash, but I've also tried it with page URL's set as either/does not matter. I've hunted around the PW API and forum and I can't seem to figure out what I did wrong. I've gotten pagination working fine in other situations, e.g. on a different template where I obtain the PageArray from a simple $pages->find with a limit in the selector. But when I instead build the array by adding to a PageArray like in my code example, then pagination doesn't seem to work. Why is this?

Thanks so much for the info! I have been testing out AOS for this purpose, which I had actually not used before. I have been struggling with trying to combine AddNewChildFirst with a previously specified sort order on the parent page. Hmm. Either it's not possible, or it's not obvious to me. I have been playing around with it but can't quite seem to do it. I have read the documentation at https://github.com/rolandtoth/AdminOnSteroids/wiki/AddNewChildFirst but I don't quite understand. It says "Unlike setting the sorting on the parent page this tweak enables manual sorting afterwards." But I don't know if that means it IS, or IS NOT, compatible with setting sorting on the parent page. If you or anyone else has any advice, I would be eager to try again. I'm probably doing something wrong but I don't know what.....! I'll explain my use case, which I imagine would be a not-uncommon one: A blogger (me) has a PW site with around 100 pages with a very flat structure. The vast majority of the 100 pages are a direct child of the home page, with very few having child pages themselves. This blogger wants to sort pages by reverse creation date so newest page is at top of page tree, which thankfully I learned from adrian's earlier comment was possible through setting sorting on parent page. Yay!! But I ALSO want to make a few pages (the ones that contain ad units that need to be updated more often) always stay at the top of that same page tree. Ad unit template is different from other pages, if that helps, but even when I set AddNewChildFirst to apply to ad unit template, it still won't allow me to move the ad unit pages to the top of the tree due to my previously specified sort order. (I do not want to manually drag and drop sort order for these 100+ pages. ) So what I'm asking overall is, is it possible to specify that the page tree get sorted first by any pages labelled as "sticky pages" always at top of tree, then the remaining pages by reverse creation date? I've updated my main post further up to mention AOS AddNewChildFirst and to reflect where I'm currently at with this.

Oh thank you!! ? Can't believe in all this time that I never thought to look there! ? I tried it out now with one of my sites and it worked! I love the range of options and reverse sort being available. Whew! That's probably my biggest PW problem and turns out the solution was already in the core all along. A huge thank you! This is why I love the wonderful community here.

I use PW on multiple websites that I admin and write content for. I'm therefore often updating my PW sites, either by writing new content (most commonly) or doing template coding, or coding other features such as logic-specific ad display. Based on my experiences across all my websites, here are my thoughts on the OP topics: Flexible content or page building - I've never needed it and can't see myself using it in the future. I already have a few things set up like footer content where I write footer-left, footer-middle, footer-right content as the body of non-templated pages, and I simply code my footer to display the body content of those 3 pages using what's already in the PW core and API. Easy, and perfect. I don't see any need for anything beyond that, such as flexible content or page building (for my purposes at least). I absolutely love the CKEditor ? and I'm not sure why or what use case anyone would want for a block editor (in fact, a block editor is a reason why I moved away from WP to PW - the WP block editor was slow and frustrating and I could achieve way faster content creation with PW). I have a few page templates where there are multiple "body" contents, and I simply use additional "body" style fields in those templates. I understand the PW CKEditor is not going to be replaced, so I'm not worried there, but I'm not doing anything that ever needs more than defining fields and displaying them with a template. Admin theme improvements - a really quite massive "pain point" for me across all my sites is the inability to order the page tree in PW admin in a way other than the default ?. When you have 90+ pages of content (which I do on several of my sites and hope to on the others later), not being able to specify a default order is very frustrating. Sure, for a 20-page site, no big deal. For anything more, it's quite hard. In particular, I'd like these 2 features: It seems both features exist, although I'm struggling to find a way to combine them. The ability (or the default) to be most recently created page at top (not the oldest created page which it seems to default to - it's basically in the reverse order of what I want.) And yes, there is the "recent" menu available in Admin, but that's not as helpful as you might think. [SUBSEQUENTLY EDITED - This feature already exists in the core! - see comment below by @adrian ] The ability to put some "sticky pages" always at the top of the page tree. For me, this would be regarding specific to ads I want to show/edit frequently, but I expect there are other people with other use cases who want certain pages to always appear at the top of the page tree. This feature is of equal or higher importance to me than changing the default order. [SUBSEQUENTLY EDITED - This feature exists in the AdminOnSteroids module - see comment below by @adrian - however, I am not sure whether or not this feature can be used with a specified sort order as mentioned in the previous point] File/media manager and more file sharing options - Yes, BUT ONLY if we can somehow specify a different alt field for an image each time that a central image is used in a new page. If that's not possible, then I'd rather stay on the default of having to re-upload the same pic separately for different pages (which is what I'm doing now anyway). For me, it's crucial that the image if used freshly in a new page, has a fresh image alt tag. Because you might want to re-use the same pic for slightly different reasons in each case. External file storage - I don't use this and can't see myself ever using this, although I can see how others might want it. I purposely like having everything on one host/location. Live preview and auto-save: Auto-save is certainly nice, but ONLY IF it does not over-ride a user-specified save. I sometimes change page content around, but then decide I don't want those changes, so I purposely don't save it. In this case, auto-save could cause me big problems if it saves the page when I did not want it to. On the other hand, I've lost content before by my own fault, by forgetting to save and then going away and my session timed out after I came back. So I certainly could use autosave as long as it saves the page in another location so as not to overwrite an existing page. Preview options are already very rich, with "new tab" and "modal" options that I use frequently, so I cannot see a use for live preview for my use cases. The existing previews are pretty amazing already! That's it from me. All of that said, I love PW, and admin-ing my sites is a breeze thanks to PW and its wonderful community of people!

This is probably something I'm doing wrong or don't understand, but I've seen on several of my websites some slight differences in PW selector results after switching my web host. Would anyone please be able to explain why this is so? It's resulted in a few unintended ramifications, although it was easy enough to fix these. In switching hosts I've also changed several things at once - the PHP version went from 5.6 ? (I know! part of why I was switching!) to 7.4. The mysql version may have changed too, but I wasn't able to look up the old one now because the domain is pointing to the new host. The new MySQL version is 10.3.27-MariaDB. I have zero SQL knowledge, and I simply look at the processwire selector docs when I want to use a PW selector, without worrying or considering what sort of SQL that might translate to. The PW version was the same at both the old and new host, 3.0.165 i.e. at the time of writing the latest master (but not dev) version. The specific problem as far as I can boil things down from tests I've done, is that on my old host, the ~= selector when used in findOne would return a page that contained all the specified words even if there were additional words to the specified one (example coming). But on the new host, the ~= selector seems to fail if there are additional words present in the field besides the ones specified. Here is an example: $adstr = "Article body end"; $thatspotinfo = $pages->findOne("template=banner-slot-info, title~=$adstr"); This will NOT on my new host allow the finding of the intended page, which is titled (without the quotes) "Article body end position 300x250". It comes up with nothing on the new host, even though on the old host this exact same selector came up with the page I mentioned. On the other hand, if $adstr is set to "Leaderboard position", then it does in fact find the intended page titled (again without the quotes) "Leaderboard position". So it seems like the extra words of "position 300x250" on the first page I mentioned is causing the selector not to find that page (although this was not the case on the old host, also I didn't change the page titles). Both of the page titles I mentioned will be found correctly if I instead use the "contains phrase/text" selector of *= Example: $adstr = "Article body end"; $thatspotinfo = $pages->findOne("template=banner-slot-info, title*=$adstr"); and $adstr = "Leaderboard position"; $thatspotinfo = $pages->findOne("template=banner-slot-info, title*=$adstr"); These find the intended pages of: Article body end position 300x250 and Leaderboard position Likewise, the intended pages are also found if I use the "starts with" selector ^= For example, title^=$adstr Am I correct in saying that the ~= selector on my new host means "contains all the desired words but only with no additional words present?" If not, what am I doing wrong? Ultimately, what selector SHOULD I be using to say "contains these words in any desired order, additional words are allowed to be present too?" For now, the workaround of "starts with" selector ^= is fine, but I'm keen to know what's going on. BTW here is a pic of the title field of the pages of interest in phpMyAdmin, which looks correct to me, I mean nothing got garbled from the looks of it. ADDED: I'm also getting the same sort of thing from moving another site from a different old host to this new one. In that case, for the record, the PHP version of the old is 7.2.34 and the MYSQL version is 10.1.40-MariaDB. The new host has PHP version 7.4.14 and MYSQL version is 10.3.27-MariaDB.

This tutorial is largely to remind myself of the sequence of steps, but if this helps someone else too, that's wonderful! I've recently moved several PW sites to another host, and I've been refining the order of steps to minimize downtime. Please note, this tutorial is for those moving a site from one host to another host, NOT for local computer to live host (although certainly the same general principles apply). This is written from the point of view where both web hosts have cPanel - for convenience I only use hosts which have cPanel. The nameservers are one of the last changes you'll make, so don't do that yet! In the old host, go to phpMyAdmin and export the database to your local computer. In File Manager, export your website files as a zip and save to your local computer. Do the same for your email files (e.g. inbox and sent folder). Please note that if you get a lot of email coming through, and/or if you do not plan to complete all the following steps quickly, you might need a more sophisticated solution so as not to miss emails while switching over. Think about what you want your new db, db user, and db password to be (I like to change all this for security reasons). Even if you wished to keep these identical, you couldn't, because your new host will automatically force a different prefix for the db and db user, so you'll wind up with a new db and db user name anyway. The next steps are all done in the new host. In MySQL Databases in the new host, create a new database, db user, and user password from what you decided above. Also, still in MySQL Databases, add that user to the database (this is surprisingly easy to forget). In phpMyAdmin, import the database you exported from before into your freshly created empty database. If your domain name is NOT the main domain name of your new hosting account, create the new domain using Add-on Domains. Otherwise, move on. Go to the main directory for that domain (if your domain is the main domain of your hosting account then public_html, otherwise the folder of your new add-on domain), and upload your zipped website files there and unzip. Go to site/config.php and edit dbname, db user, and user password so that they match the new ones you set up. At this point, be sure you at least have a plan for SSL before moving forward. If your host does AutoSSL that's probably the easiest, at least to get started. If not, or if you're doing e-commerce, look into purchasing a new SSL cert that fits your requirements, either through your host or via a 3rd party if your host allows installation of 3rd party SSL certs. Just as importantly as minimizing downtime, you'll also want to minimize the time your site is without SSL. Then, and only then, change your domain's nameservers at your domain name registrar to point to the new host. Once this change is live, set up SSL right away - however you want to do that is up to you. For cPanel hosts running AutoSSL, just go to SSL/TLS Status and click on "Run AutoSSL" - wait until that domain's status turns green, it could take several minutes. Finally, set up your email on the new host and move the mailbox folders over (don't forget the "sent" folder!) Optional: If you have Softaculous (which I highly recommend for its auto backup capabilities), go into Softaculous, go to "ProcessWire" and click on "Import" and go for the local option not the remote one. Select your site in the fields and it will automatically import your PW installation. Then to set auto backup schedule, still in Softaculous, go to "all installations" at the top right menu, then on your list of installations go to "edit" (the pencil symbol) next to your new domain's installation. Leave all details the same except for "Automated backups" - select your desired backup rotation options and then click "Save installation details".

I had this exact style of error message also when moving from one server to another, in my case it came from a different issue than the OP (OP's looked to be a problem with the web host). In case anyone else is also experiencing this, I found I had made a simple error: on my new host where I created a new database user, I had forgotten to add the database user as a privileged user of the database. Doing that fixed the problem: in a cPanel host, just go to Databases > MySQL databases and then "Add User to Database". After making that change, my site was live! Yes, it's a total facepalm moment on my part, but it IS surprisingly easy to forget after creating a new database and importing the old one into it, then creating a new db user and password, changing the equivalent credentials in site/config.php to match the new info and... it doesn't work! So when creating the database user, remember that it needs to be added as a privileged user of that database.

I'm coming in late to this discussion sorry. A huge thank you to @Christophe for bringing this thread to my attention. I had a strong need for the Schedule Pages module but was hesitant to use it on my PW 3.x site as the documentation was unclear whether it is compatible for 3.x. But the comments above from @3fingers, @teppo, and @Zeka seemed encouraging about the safety of using Schedule Pages on a 3.x site. So finally I decided to install it on one of my 3.x sites and I can attest it worked perfectly! Be aware that my test case is a simple one: my site GoodKidsClothes.com doesn't have anything unusual about it from a development perspective - it's a blog that has been going for several years and has a decent amount of content, but there's nothing complex. It displays articles I've written. Extra details about my experience installing and testing Schedule Pages are shown below. Firstly I do want to point out that the manual solution of clicking the publish button on the page on the correct day is technically do-able, but is not ideal in many situations, and certainly not in the situation where I would use it. On those occasions, which fortunately are not frequent, this has entailed me getting up at 3am to press the "Publish" button (explanation below). So yes, it's do-able, but not ideal. Here is the real-life use-case I'm talking about: a brand I am promoting wants my article to come out as early as possible on day x. This means timezone has an effect. "As early as possible on day x" for a U.S. brand really means 3:01 a.m. US Eastern Time (= 12:01am US Pacific time) on day x. I cannot just publish the minute it turns to the next day here on Eastern Time because that is still the day before on Pacific Time. For brands that have time-sensitive news and deals, I am not allowed to leak it the day before, even if I'm in another time zone than the leak. A breach in trust like that is serious and would result in the brand severing any relationship with my site. So it's not just the day, but also the time, that is critical here. I can attest that Schedule Pages works fine on all counts. When I installed the SchedulePages module, it did come up with a warning: However, I carried on with the install and it all went fine and the module worked perfectly. A huge thank you to all of those who posted above, and especially the people I mentioned personally in my comment here, as it inspired me to try the SchedulePages module. You've all literally saved me from a 3am wakeup next week for a post that needs to be scheduled ??? I'm sure all the other solutions people mentioned would have worked fine too, but I like to use modules to limit the amount of custom coding I need to add on my own. A couple of points to note about SchedulePages (besides what others have said): For first-time users, while the date picker is straightforward, the time entry part of it to schedule the post might be a little bit confusing. It certainly took me a few tries to work it out. The default time on the field says something like hh:24:11:ss , but basically you should just enter whatever 24-hour time you want like this: 14:34 (I didn't worry about adding seconds, and it just set seconds to zero). For others such as myself who have time-critical needs, SchedulePages seems to take it from timezone of the site (site/config.php ?), which is what you'd typically want, and not from the server time. I tested out the module using same-day and next-day scheduling. My server time is US Central Time, and my site is in US Eastern Time according to site/config.php. Based on setting my LazyCron to 5 min intervals and testing my schedule pages publication times, it looks like the time is being taken from my site time (US Eastern), which is exactly what I want, and not from my server time (US Central time).

A huge thank you to @Gadgetto for this tutorial. This is my first time with multi-language, and Gadgetto provided the perfect tutorial for beginners such as myself to learn from. I worked my way through the tutorial and can attest it works beautifully and I could follow along without getting lost. I now have a wonderful language switcher on my site AND the html lang tag AND the href lang alternate tags, all thanks to Gadgetto's great tutorial above. The screenshots were really helpful too. His code really should be a must-read for those making their first multi-language site. Thanks again! ?