Overriding login page from add-on
Permalink
I'm building an addon for C5 that changes the login page (and controller) to add extra functionality. When I copy login.php from /concrete/single_pages into /single_pages, it works like a charm -- my modifications show up without me having to write any extra code.
But when I put the very same file into /packages/my_addon/single_pages, it no longer works. In fact, the only way I can get it to work is if I delete (usingthe login page from /concrete/single_pages and adding it again from /packages/my_addon/single_pages using the single_page helper.
Of course this is not an ideal way to do it. If my code failed to run or a C5 upgrade did something, you could potentially lose your login page.
Looking in the Environment library, there is a function,, but calling it does nothing.
Can anyone shed some light on how to correctly do this? And instead of copying the whole login.php file into my packages directory, can I "extend" the functions I need, then call the original (parent) function to do the rest?
But when I put the very same file into /packages/my_addon/single_pages, it no longer works. In fact, the only way I can get it to work is if I delete (using
Page::getByPath('/login')->delete();
Of course this is not an ideal way to do it. If my code failed to run or a C5 upgrade did something, you could potentially lose your login page.
Looking in the Environment library, there is a function,
Environment::overrideCoreByPackage($segment, $pkg)
Can anyone shed some light on how to correctly do this? And instead of copying the whole login.php file into my packages directory, can I "extend" the functions I need, then call the original (parent) function to do the rest?
Yep, it's for the marketplace. It's actually going through the PRB at the moment, and one of the discussion points is how to safely override the login page without it or the site getting nuked by a future upgrade, which is why I asked here.
And I did read the third rule, but assumed it was to stop people making themes or addons that got greedy and overrode core styles when that wasn't the authors intention (for example, a theme that uses the * selector and breaks the dashboard menu because the author was too lazy to write the correct syntax)
This addon's sole intention is to add a second level of authentication to the login page and the documentation clearly explains what they're getting, so I'm hoping there won't be a problem when it comes down to the final decision.
And I did read the third rule, but assumed it was to stop people making themes or addons that got greedy and overrode core styles when that wasn't the authors intention (for example, a theme that uses the * selector and breaks the dashboard menu because the author was too lazy to write the correct syntax)
This addon's sole intention is to add a second level of authentication to the login page and the documentation clearly explains what they're getting, so I'm hoping there won't be a problem when it comes down to the final decision.
In our bible of rules there is the following
"3) Does it adhere to the package format, not overwrite core styles or code in a way that makes the site un-upgradeable or likely to collide with other add-ons/themes."