Setting up new PageTypes as part of a package
Permalink
I want to make a Package that pulls in all the components necessary to run a client's website and preinitialises a number of default pages so that the basic hierarchy is in place. The idea is that the client can just deploy a default Concrete installation and then install this single Package and it will pull together all the components necessary to let them start populating the site.
One of the things that I would like to do is to create a number of new PageTypes with the appropriate default layouts for the PageTypes so that when I create the default pages they have the right Blocks registered on them already. However I am having problems finding documentation on how to do this via the /packages/xxx/page_types directory. Can anyone point me at the right place to read up on what files should be placed in this directory and the responsibilities and syntax that they have?
One of the things that I would like to do is to create a number of new PageTypes with the appropriate default layouts for the PageTypes so that when I create the default pages they have the right Blocks registered on them already. However I am having problems finding documentation on how to do this via the /packages/xxx/page_types directory. Can anyone point me at the right place to read up on what files should be placed in this directory and the responsibilities and syntax that they have?
Thank you very much - it is very helpful.
At the risk of moving the thread off topic - if I am setting up packages that do lots of work building stuff and I want to run them repeatedly during development then is there an easy way to reset a Concrete 5 implementation to the absolute default - ie no custom extensions, no pages, no data? It would be really useful to have a single button to just say "reset" and then I can re-import my package, check that it is better and repeat.
At the risk of moving the thread off topic - if I am setting up packages that do lots of work building stuff and I want to run them repeatedly during development then is there an easy way to reset a Concrete 5 implementation to the absolute default - ie no custom extensions, no pages, no data? It would be really useful to have a single button to just say "reset" and then I can re-import my package, check that it is better and repeat.
Hmmm. That would definitely be helpful, but off the top of my head I'm not sure of a way to do that. I'll check around and if I find anything I'll post it.
Interesting requirement.
I think this is best done at the server level (see mike's "demo server" link below), as you'd theoretically want to clear out the files as well.
c5 is pretty good about clearing out most package-related stuff (blocks, etc) when you uninstall. But it's not perfect... I think it clears single pages for example. If it's not, you might want to confirm that you're setting the pkgID correctly and in the correct place.
Personally, when I create "install packages" like yours, I make sure that they can handle upgrading (ie, they check if the page type is installed and install it if it's not). This is presumably required after the site goes live. So I develop like that, upgrading and upgrading, assuming that if the initial install worked, and the upgrade installs worked, then a clean install will work. Then, I make sure to test a clean install at least once. I feel that that's a pretty thorough workflow.
I think this is best done at the server level (see mike's "demo server" link below), as you'd theoretically want to clear out the files as well.
c5 is pretty good about clearing out most package-related stuff (blocks, etc) when you uninstall. But it's not perfect... I think it clears single pages for example. If it's not, you might want to confirm that you're setting the pkgID correctly and in the correct place.
Personally, when I create "install packages" like yours, I make sure that they can handle upgrading (ie, they check if the page type is installed and install it if it's not). This is presumably required after the site goes live. So I develop like that, upgrading and upgrading, assuming that if the initial install worked, and the upgrade installs worked, then a clean install will work. Then, I make sure to test a clean install at least once. I feel that that's a pretty thorough workflow.
At present I'm having to write equivalent functionality in uninstall() to balance out what I'm doing in install(), but I am never intending anyone to actually run the uninstall() function once it gets out of dev so it feels a bit like wasted effort. I'm also not confident that my install() and uninstall() functions are *truly* symmetrical so I don't know that I'm going back to a "clean slate" for each iteration.
I had hoped that setting the pkgID in the $data that I'm passing to the page creation function would mean that when I uninstall the package that the pages would just go away but that doesn't seem to be the case. :-(
I had hoped that setting the pkgID in the $data that I'm passing to the page creation function would mean that when I uninstall the package that the pages would just go away but that doesn't seem to be the case. :-(
If you check out the package c5 Boilerplate (http://www.concrete5.org/marketplace/addons/c5-boilerplate/) in the marketplace, hereNT actually gives a really good example of doing this in his package controller at /controller.php in the installPageTypes() method. If you want to check out the code directly you can see it on github here:https://github.com/herent/c5_boilerplate/blob/master/controller.php#...
Hopefully that helps!