AAD Web Team

Great, thanks for that! I’ve implemented a constructor and it seems fine. I initially made a mistake by including a reference to a page that has no view of its own, but contains some general website settings, like this: public function __construct(Template $tpl = null) { parent::__construct($tpl); $this->siteSettings = pages('/site-settings/'); } This caused an infinite loop because the site-settings page itself uses the DefaultPage class. To get around this I created an empty class for the site-settings template, like this: class SiteSettingsPage extends Page { } I’m not sure if this was the smartest solution, or if the idea of having so much code in DefaultPage is a good idea. I wonder if there are a heap of system pages and other things that I’m not thinking of, which are inheriting from DefaultPage?

If we’re using custom page classes, is it acceptable to have a constructor, or does that cause problems by overriding the constructor that should be running in the parent Page class? Should we call the parent class constructor? For example in /site/classes/DefaultPage.php, would this be correct? class DefaultPage extends Page { function __construct() { parent::__construct(); // … set some class properties for later use … } }

Great, thanks! I put the try/catch around the $db->query() method rather new WireDatabasePDO constructor and it worked well.

Is it possible to connect to a non-ProcessWire database using WireDatabasePDO, and have error handling, so if the database is unavailable then the page can recover gracefully? I tried: try { $db = new WireDatabasePDO([ /* dsn, user, pass */ ]); } catch (\Exception $e) { /* Code to handle the problem gracefully */ } This doesn’t work – it seems that the exception is dealt with by ProcessWire before my code sees it. Is it better just to use PHP’s native PDO object directly? Something such as: try { $dbh = new \PDO($dsn, $user, $password); } catch (\PDOException $e) { /* Code to handle the problem */ }

This is still an ongoing issue for us. We want to try testing it on some of our other sites as well. Was more just checking if anyone else had ran into the issue before.

Thanks @wbmnfktr- I checked and the template is set to Option B: Show the Login page:...

I was a bit worried about the 191 number, given ProcessWire uses indexes up to 250 characters. However, the maximum length of a utf8mb4 index would be 191 only if the InnoDB table uses compact or redundant row format. If your InnoDB table uses compressed or dynamic row format then you can have up to 768 characters (3,072 bytes) in a utf8mb4 index. I’d never paid attention to row format before, but I checked all our databases, which are up to 5 years old, and they all use dynamic row format. This SQL command gives the row format information, among other things, for a database: SHOW TABLE STATUS IN my_database;

We've just confirmed this also happens when manually setting a redirect in a page's settings via the admin panel. So perhaps it's due to the way the core handles redirects?

Hello all. We've notived a potential bug with redirects that go to a restricted page (a page that guests cannot view, and the user is currently not logged in). We have a page that contains a form that people can use to post news items to a section of our site (like a noticeboard). This page template requires to used to be logged in so we can atrribute the post to the user. We've noticed that if the link to this page is a redirect (due to the page moving and the PagePathHistory module being installed), then rather than direct the user to login, it presents a 404 page instead. Normal behaviour is clicking a link to the this page will send to user to login, once a successful login is made it continue them onto the restricted page they were trying to access. Is this a potential bug or could we be doing something different to prevent this?

From time-to-time we end up with an infinite loop in the PagePathHistory module. The effect of this is that someone clicking on "What other URLs redirect to this page?" in the admin interface justs get the spinning icon. In the error log we get an entry about the allowed memory size being exhausted in PagePathHistory.module. Inside the module, the getVirtualHistory method is being endlessly called, alternating between two different page ids. This seems to happen when we have two pages like this: Page 1 URL: /one/two/three/ Old URL: /one/four/ Page 2 URL: /one/two/ Old URL: /one/four/five/ The only way to fix this seems to be to log into MySQL and delete rows from the page_path_history table. Ideally we'd like ProcessWire to either stop users adding new redirect URLs that cause this problem, or to somehow handle and escape from the infinite loop that results. Is there a modification to the code that might achieve this?

I'm looking to add an icon next to the page title in the page tree, similar to how pages in draft state (with ProDrafts) can be identified by the little paperclip icon. What is the best way to go about this? I tried diving through the source code of a few modules and I suspect I need to hook into 'ProcessPageListActions::getExtraActions'?

We often get this error ("This request was aborted because it appears to be forged."), but for us it's due to people pressing the "Login" button more than once (or pressing the enter key followed by the Login button). Someone in our group of web authors does this about once per day on average. For us it'd be a useful system change if the Login button was immediately disabled via JavaScript after clicking (or pressing enter) so that it couldn't be activated twice. (I wonder if there would be any downside to this change?)

Thanks @Craigand @flydevwe have now resolved the issue. Clearing the cache was good for temporarily unlocking space in blocks to get through. Turns out the issue was a recent code change where the Pageimages class was used for handling a group of Pageimage's from across many pages (where we'd previously use an array) - we had not realised at the time that this leads to each image getting instantiated again (and therefore duplicated)!

Hello, Brodie from the Australian Antarctic Division here. We've got some kind of suspected cache issue casuing runaway disk usage, it's currently so bad that our websites are down (unless logged in) and I cannot SSH into the servers. A restart of both the database and hosting server have not helped either. Pages load fine when logged in (since the cache is skipped) or when disabling the cache. Below are some of various error messages we've started seeing, I suspect due to running out of disk space: Unable to write lock file: /site/assets/cache/LazyCronLock.cache Error: Exception: Unable to copy: /site/assets/files/26153/keon-anzac.jpg => /site/assets/files/26151/keon-anzac-7.jpg (in wire/core/Pagefile.php line 236) unlink: Unable to unlink file: /site/assets/cache/Page/45511/4df366e0700b7c24883b744b6cb250ee+https.cache Has anyone had a similar issue before and knows something we could try to resolve it?

In our page template cache settings we have, "Clear cache for saved page and parents", which works as expected when using ProcessWire (3.0.200) interactively. When we manipulate pages with the same template from the API though we get this: $page->save(); // Cache clear happens as expected $page->save('my_field'); // Cache clear is not triggered – it's as if the page has not been saved (though the field has been saved correctly). $page->setAndSave('my_field', $value); // Cache clear is not triggered Is this the expected behaviour? If so, could the $page->save() documentation be updated to mention this difference?