Overriding default single pages from a package
Permalink
Question: Is there API support for overriding a system page (specifically, /profile) from a package? If this isn't considered a best practice, what should I be doing instead?
If there is no clean answer, I realize I can always make a different page, perhaps under /profile, but I would like something that integrates well with existing pages and profile management.
Background:
I customized /profile in the DIR_FILES_CONTENT/single_pages directory, and this works fine. However, it's not picked up when I move it into a package. As it turns out, if you call SinglePage::add($path, $pkg) for a path that already exists, the code exits without making any changes. Then, when you view it, the code path in View::render has this flow:
Basically, it will only look in a package directory if one is specified, which is never the case for system pages like /profile. Then I looked into setting $pkgID on the /profile Page object during the install() routine, except that Page::update only updates the pkgID of a page as a side-effect of changing the page type, which doesn't help for a single page. However, as a proof of concept, if you hack around this and jam the pkgID into the page, it works exactly as I would like (it uses packages/my_package/single_pages/profile/view.php).
Discussion:
Should SinglePage:add() indicate an error condition if the page already exists?
Should Page::update() support changing the pkgID? I realize that this opens a potential conflict when changing the CollectionType simultaneously.
If there is no clean answer, I realize I can always make a different page, perhaps under /profile, but I would like something that integrates well with existing pages and profile management.
Background:
I customized /profile in the DIR_FILES_CONTENT/single_pages directory, and this works fine. However, it's not picked up when I move it into a package. As it turns out, if you call SinglePage::add($path, $pkg) for a path that already exists, the code exits without making any changes. Then, when you view it, the code path in View::render has this flow:
// pulled from render() in page.php, v. 5.5.1 if (file_exists(DIR_FILES_CONTENT. "{$cFilename}")) { // ... get it from the override directory } else if ($view->getPackageID() > 0) { // if was installed as part of a package, get it from that package's directory } else if (file_exists(DIR_FILES_CONTENT_REQUIRED . "{$cFilename}")) { // otherwise get it from the concrete/ directory }
Basically, it will only look in a package directory if one is specified, which is never the case for system pages like /profile. Then I looked into setting $pkgID on the /profile Page object during the install() routine, except that Page::update only updates the pkgID of a page as a side-effect of changing the page type, which doesn't help for a single page. However, as a proof of concept, if you hack around this and jam the pkgID into the page, it works exactly as I would like (it uses packages/my_package/single_pages/profile/view.php).
Discussion:
Should SinglePage:add() indicate an error condition if the page already exists?
Should Page::update() support changing the pkgID? I realize that this opens a potential conflict when changing the CollectionType simultaneously.
