Leaderboard

This week ProcessWire 3.0.217 is released with 10 issue fixes, 2 PRs and a couple of minor additions too. See the dev branch changelog for details. Recently a client called me in a panic because they'd spent a few hours making edits to a page, and when they finally hit save, they were no longer logged in, so their changes were seemingly lost. I guess that their IP had changed somehow, or they kept the page editor open overnight or something. Whatever it was, they were now sitting at the login screen with their changes apparently lost forever. Luckily this person left that window as-is and contacted me to see if there was any way I could recover their changes. I quickly edited their /site/config.php file and temporarily added these: $config->protectCSRF = false; $config->sessionFingerprint = false; Next, I asked them to open another tab and login there. Once logged in, they returned to the tab where the page save failed, then hit "reload" in their browser, and their changes were saved. Phew. Thankfully that worked, but if it didn't, the next thing we were going to try was to open the browser inspector "Network" tab, and then copy/paste the edited content right out of the browser's POST data and into the CKEditor HTML source window. I imagine this has happened to others and perhaps they weren't so lucky as to recover the unsaved changes. So how can you avoid this issue? The best bet is to just save your work regularly. But that doesn't always happen, no matter how many times we communicate that to the client. So you can reduce the probability of it by making a couple adjustments to your config.php file. One change would be increasing your $config->sessionExpireSeconds. But the default is already 86400 seconds (1 day), and I'm not sure many really take more than a day between starting an edit and saving it... though I'm sure it happens. Another change would be turning off the $config->sessionFingerprint (or loosening it, see fingerprint settings). That's trading security for convenience, which isn't ideal, but it would prevent a changed IP address from expiring the session. Another thing you can do is install the ProDevTools UserActivity module, which keeps a ping going to the server, preventing you from getting logged out due to inactivity. Though this doesn't prevent a changed session fingerprint from logging you out, though it at least alerts you as soon as you've been logged out. Even the above changes might not completely solve this issue, and I don't like to tailor session settings around this case either (reducing security), so I've been thinking of alternatives. After dwelling on it for awhile, I started working on a module that saves non-authenticated POST requests sent to the page editor... saving data that would otherwise get lost. Then when you go back to edit the page, it alerts you that there are unsaved changes and asks you if you want to save them. When you answer yes and hit "save", it repopulates the unsaved POST data back into $input->post before the page editor has had a chance to process it. There are of course some security considerations here, so it has to be built carefully. I should also mention that it won't help much if it's the client's computer or browser that has frozen (there's the PageAutoSave module that can help with that). Though data loss due to a frozen computer/browser is likely even more rare than session loss. I don't have this module fully working just yet (it's a work in progress), but it's relatively simple so it probably won't take long. It's not going to catch everything; it won't save files, for instance. But it will catch the most likely cases, such as changes to those big "body copy" fields that someone might spend hours making edits with. I'll post more about it when I've got it a little further along, if there's interest. Thanks for reading and have a great weekend!

That's going to be a problem. ProcessPageView::execute is responsible for calling ProcessPageView::renderPage or ProcessPageView::renderNoPage, which are the two methods responsible for catching and handling 404 exception. In this case you're preventing the core from doing what it would normally do. Instead of looking for workarounds (which may not exist), it's easier to just handle segments in templates, or define allowed segments (as discussed above). If you need to serve a page from an URL below home page that doesn't match an actual page, and this needs to happen in a module, it's better to leave URL segments out of the equation (just keep them disabled) and instead use URL hooks or hook to ProcessPageView::pageNotFound.

Suggesting ProcessWire to your boss. It tend to be similar to answers above, maybe she mean your boss could be your client ?? —- Simple: I can provide you with some key points and resources that you can use to build your own compelling argument in favor of ProcessWire over WordPress. You can use these points to create a presentation, write an article, or as a guide for discussion. 1. Flexibility and Customizability: ProcessWire is known for its flexibility and customizability, making it an ideal choice for projects that require a tailored approach. It allows developers to build custom data structures and tailor the admin interface to suit the specific needs of the project. 2. Simplified Template System: ProcessWire's template system is simple and straightforward, providing developers with the freedom to create custom templates with ease. Unlike WordPress, there is no need for complex themes, which can make site development and maintenance more efficient. 3. Security: ProcessWire has a strong emphasis on security, with built-in protection against common web attacks such as SQL injection and cross-site scripting (XSS). WordPress, on the other hand, can be vulnerable to security issues due to its popularity and the use of third-party plugins. 4. Performance: ProcessWire is known for its fast performance, as it uses an efficient API to access content. This can result in faster page load times, a better user experience, and improved SEO. 5. Developer-friendly: ProcessWire's API is powerful and easy to learn, which can lead to a more efficient development process. It provides a cleaner and more organized code structure, making it easier for developers to maintain and update the website. 6. Supportive Community: ProcessWire has an active and supportive community that can provide help and resources when needed. Although smaller than the WordPress community, it is known for being welcoming and helpful to newcomers. —- Business focused answer: Here are some business and financial-focused arguments for choosing ProcessWire over WordPress: 1. Lower Total Cost of Ownership (TCO): ProcessWire's flexibility and customizability can lead to a lower TCO. Since it is easier to develop and maintain custom solutions, your company may require fewer third-party plugins, themes, and external resources, which can reduce ongoing costs. 2. Faster Development Time: ProcessWire's straightforward template system and powerful API can speed up the development process, allowing your team to deliver projects more quickly. This can result in reduced labor costs and a faster time-to-market, giving your company a competitive edge. 3. Improved Site Performance and User Experience: Better site performance and user experience can lead to higher conversion rates, better user engagement, and improved SEO rankings. ProcessWire's performance advantages can directly contribute to increased revenue and profitability for your business. 4. Reduced Security Risks: Since ProcessWire has a strong emphasis on security, your company can minimize the risks associated with data breaches, cyberattacks, and website downtime. This can save your business from potential financial losses, legal liabilities, and damage to your brand reputation. 5. Scalability: ProcessWire is highly scalable, making it suitable for businesses that plan to grow and evolve over time. Its flexible architecture allows you to easily adapt and expand your website as your needs change, without having to invest in a complete overhaul. 6. Easier Staff Training and Onboarding: ProcessWire's developer-friendly API and clean code structure make it easier for new staff members to learn and become productive quickly. This can lead to reduced training costs and faster integration of new team members, further improving your company's efficiency. 7. Long-term Investment: By choosing ProcessWire, your company is investing in a platform that is built for long-term success. Its flexibility and customizability ensure that your website can evolve with your business needs, reducing the likelihood of needing to switch platforms or undertake costly redevelopment projects in the future. When presenting these points to your boss, make sure to emphasize how ProcessWire's features can translate into financial savings, revenue growth, and a stronger competitive position for your company. Tailor your arguments to your organization's specific needs and goals to make the most compelling case possible. ??

Depending on how you're handling unrecognized URLs, this could be a feature (sort of). If you enable all URL segments and don't throw 404 with the Wire404Exception::codeFunction code (or via wire404() function), no further hooks will (or should) be executed. See wire404() function docs (and/or function definition) for more details. ... though if you're already handling them as described above, then it's likely a bug ?

ga beer -- u.try this in home.php ? if ( $input->urlSegment1 === 'files' ) wire404();

Sounds like a bug to me and might be worth creating an issue on github? Other than that: Have you tried limiting allowed url segments via regex? Just tried with a regex that allows all url segments except ones starting with "test" and it worked: regex:^(?!test).*$ In home.php bd($input->urlSegment1); And the hook in init.php: $wire->addHookAfter("/test/{file}", function ($e) { bd($e->file); }); /foo/bar/ --> shows "foo" /test/foo.jpg --> shows "foo.jpg"

I’ve found that the most irritating situation is when the editor leaves a page open, then comes back to it some time later and makes a big edit only to find it won’t save because they’ve been signed out. The UserActivity module fixes this nicely, but it would be better if it was fixed in the core. Just a simple message to say you’ve been signed out would help.

Sure, there is. As always :) Thanks in advance. Have a great weekend everyone!

@teppo I just opened an issue regarding deprecation warnings.

Most of the times I use redirects for temporary purposes, usually for short links that should change over time (for example, `https://mysite.org/conference-signup`). So it was important for me that this module could redirect with other status codes, mainly 302, instead of 301. I haven't created any ProcessWire modules yet, but I decided to try and improve apeisa's module, and I got it to work like I wanted, so I thought I should contribute this to the community. I know I should make a pull request, but I'm not experienced in git yet and I have little time now, so the best I can do now is leave here the file for you to see if you want. I'm sorry for this. I added a column "status" to the table process_redirects, like this: `status` enum('301','302','303','307') NOT NULL DEFAULT '302', I only used the status codes specified on the documentation for $session->redirect. In future I'd like to specify them in a constant or static property (not sure), and then use it to generate the options in the edit form. I haven't bumped version, and I'm not sure how to procceed about updating the database schema. Could you have a look, please? ProcessRedirects-tomasanjosbarao.module

@teppo Your a rockstar sir! Thanks for the quick options on this. Where can I send you a beer? Cheers!

Thanks to everyone for your valuable input. Here are my findings after having tested this on a fairly virgin multilang install with root URL in default language redirected to /en/ through LanguageSupportPageNames setting and URL segements enabled on the home template. After putting in anything in the URL segment whiltelist, the URL hook works. And of course, like @bernhard suggested the regex option makes total sense. Great idea if you control behaviour from within the template file. And this also proofs that URL hooks are kicking in right befor showing the 404 page. I enabled all segments by leaving the whitelist empty. Then in my PageView::execute hook, that handles display of pages by URL segment, I am throwing a 404 with `throw new Wire404Exception();` This throws an Exception and doesn't show 404 or execute my URL hook. Seems like we can use wire404() or throw new Wire404Exception only in template files? My hook is triggered inside init() of an autoload module. My conclusion: if you have URL segments enabled on the home page and want a URL hook to execute, you need to have a whitelist for URL segments defined. Thanks again to everyone. Now if you can tell me how I can throw a 404 without getting an Exception in my autoload module, that would be awesome ?