AAD Web Team

Thanks @Robin S, that worked perfectly! We are now supporting LDAP login and automatic initial account creation for both email and username (samaccountname).

If I have a Datetime field on my page and the field is not empty then the getUnformatted method returns the integer for the Unix timestamp (as expected), but if my field is empty then getUnformatted returns an empty string. I would have expected it to return the integer 0 as that's the raw value for an uninitialised timestamp. I think this is unintuitive, and inconsistent with the way the system datetime fields work. With two non-empty dates (using the current timestamp as an example), you get compatible results: $page->getUnformatted('my_date') === 1750221096; $page->getUnformatted('published') === 1750221096; $page->getUnformatted('my_date|published') === 1750221096; With two empty dates (e.g. if the page hadn't been published yet) you get incompatible results: $page->getUnformatted('my_date') === ''; $page->getUnformatted('published') === 0; $page->getUnformatted('my_date|published') === null; I think the getUnformatted method should return an integer 0 for an uninitialised date. Does that sound reasonable, or is there a particular need for it returning a string instead? I can see that returning a string could be handy if you want to distinguish between an empty date and a date that's actually set to 1 January 1970 at 00:00. If that's the logic to it then I'd submit a pull request for the documentation to be changed so that it's clear what getUnformatted returns with Datetime fields.

Thanks for the suggestion @Robin S, hooking ProcessLogin::loginFailed() unfortunately does not allow us to amend the username before the login is attempted. If an email address is detected, we want to look up that email address in Active Directory and swap the login request to using the user's username (samaccountname). The following hooks do NOT trigger when an email address is used as the username, regardless of email logins being enabled/disabled: ProcessLogin::loginAttempted ProcessLogin::loginAttemptReady ProcessLogin::login ProcessLogin::loginFormProcessReady ProcessLogin::loginFormProcessed All the above hooks trigger for a username, and allow the username to be caught and changed before the login is attempted. A hook to ProcessLogin::execute will trigger with an email address login, but we haven't been able to figure out how to catch the username/email argument and change it before the login is attempted.

We're in the process of our organisation switching the naming convention of usernames to be email addresses. As part of this change we are looking to support users logging in with their old username (of which the format will still be supported for a while) or their email address. We have a custom module which hooks a login attempt. If the user is not found in Processwire, then our Active Directory is queried and if the user is found there (and the password matches) then the user is created within Processwire. This functionality needs to be retained for email logins. In our testing, we have set the ProcessLogin module to allow emails or username logins. If we try to login using an email that is not currently associated with a user, then we get an error message but the login hook does not trigger, and the session log does not get updated with any entries of a failed login attempt. If we try to login using the email address of an existing user, but using an incorrect password, then this does trigger the hook and logs a failed login attempt (using the found username) to the session log. Is there a reason the behaviour is not consistent? It would be better security to log a failed email login attempt, even if a user with that email address does not exist. In our case, we would like a failed email login to still trigger the hook in our module that should then find that user by their email address in Active Directory. Can we achieve this?

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'?