The code that I needed to figure out for my new page manager application is almost ready. I'll be able to start making a ton of new applications in a very short amount of time.
I've been working on building an application framework that will allow for extremely rapid development of new applications. I wanted to make it so you could either use the GUI or set things up in code to make things like recipe managers, testmonial packages, blogs, etc. So far, I've only gotten the core of the system out into the marketplace. It's still in a somewhat rough form there, but even at that stage of development, it is really quite robust even if it does require a bit of manual configuration.
What's been holding me back a bit was figuring out how to actually set everything up via code. It's no big deal to add the pages from the front end, but setting it up in a package is really complicated.
First off are the permissions that you need to apply to the dashboard and task permissions to allow a group to access the composer application. To get an idea of everything that needs to be set, you can check out this tutorial on allowing access to composer here. It's one of the clunkiest aspects of using my system. If you set up a new composer page type, and only want some users to be able to access it, you have to spend 10 minutes or more configuring everything. Certainly a big barrier to usability for site administrators and developers.
The next thing is figuring out how to set up your page type with all of the content and attributes to actually work in composer. This is pretty straightforward from the Page Types section of the dashboard, but doing it from code is not really documented anywhere.
Obviously, I've been wanting to automate those two things since I first came up with the idea for the package. But there simply hasn't been time to really spend on it. Right now, I'm kind of between freelance projects, so I have some time to actually work on it. I got a bit distracted on a couple of other marketplace addons, like my Vegas full screen slideshow and another super-secret project that's still in development.
But I do have another project (also mostly secret) that I'm working on. It's probono, but I'm really, really stoked about it. It might end up being a huge boost for concrete5 in general, and hopefully send a lot more projects my way. I've been falling behind on it, so this week was spent digging in quite deeply.
One of the things that the site needs is a way for people to submit a particular page type for consideration, and then allowing the administrators to approve it. I could have made a simple custom form for it, but I wanted to do something a bit more functional. So, why not set up everything in composer, and use my page management application to control everything?
It would have been really simple to just set everything up using the built in GUI tools. And for a lot of developers, that would have been quite enough.
But I really like to keep things in a package. Synchronizations between live and development, addition of new features? That's all much, much easier when it's in a package. If you set it up with the GUI, then you can run into issues later on. If you sync up with the live version of a site, and it's missing an attribute that now relies on that attribute to display? Suddenly you have a couple of hours trying to figure out exactly what you had before and recreate it.
A total waste of time.
I always want to try and make my applications re-usable and ready for the marketplace. So I wanted to do everything in the package controller for the application. This weekend, I worked almost continuously to make that happen.
Changes to the Core
I had to make some changes to the page manager application first. I really wanted to put the page manager application on the front end, honestly, a bit just to see if I could. So I created a clone of the dashboard theme because apparently you can't get the dashboard theme through the API. I'm not sure why I really wanted to put it on the front end, since in order to give people access to write the composer pages, they need access to the composer section and the sitemap. So I could have done it there.
In the final marketplace versions, I might do that. But 3 or 4 versions down the road, I want to allow you to make everything front-end only. That way applications could be made that don't show the edit bar at all for the people managing the page. I'm not sure how workable that is going to be, though. On the pages where they can add a sub-page, they'll see the edit bar anyway. If it's only the file manager, site map, and managers they are in charge of that people are allowed to access, then it's not that big of a deal to allow people dashboard access.
I think I'm going to have to change my code for tweaking the dashboard sub-page permissions, though. Right now, it only explicitly excludes everything in a default install besides a couple of pages. I need to reverse that to get all pages underneath the dashboard, and then only allow access to the two pages that they should have. That's a pretty simple change, though.
So, yeah, that was probably a bit of a wrong turn to set it up to work on the front end, but it seemed like a good idea to at least try it. And it could be kind of nice for the future. If you look at the ProBlog package, it has a front end manager. Of course, it is just shown in the site theme, so the styling can be really awful. That's why I wanted to make sure that I could use the completely dashboard styling on the front end. If I clone the sitemap and file manager pages into page types, I could make it all completely front end, and not allow any access to the dashboard at all.
Configuring the Page Types for Composer
After that, I needed to actually get the pages set up for composer. I spent a large portion of Saturday working on that aspect. There are a ton of different attributes and a few blocks that needed to be associated. I had never done that before, but in the end it wasn't all that difficult. Of course, the end was after spending a ton of time digging through the code in the concrete5 core. This kind of thing isn't really included in the documentation.
This is going to be the biggest thing to work on for the other applications that I want to make. They'll pretty much be a page type and a few blocks, with the real meat of how the application works built into the pacakge installation, which will call the API on the core. I'm quite comfortable with installing page types, attributes, blocks, etc within a package. I even made a package to teach other people how to do these things.
But then taking everything that you've created and then set it up in composer? That's a whole new level of complexity.
Now that I know what to do, it's just a matter of naming the page types and attributes differently, and then I'll be able to make a completely different application.
A whole lot of my planning and thinking about an addon is in the naming conventions. I try to make it all semantic, even if it's a lot more verbose. It can be a bit more complicated to program, but in the end, it makes for code that is much easier to read and expand upon.
I think that planning an application is as important as actually writing the code. Often I spend several days or more simply trying to think of what will happen in the application. No code. Maybe an outline of the models and the functions, some database schema in a google doc, but that's it. Then stubbing in everything into a package, and writing a ton of configuration into the package controller. At that point, 70-80% of the app can be done. Sure, you might have four days into it, but you can be working on other stuff like the theme while you are ruminating on the overall application structure.
Figuring Out Permissions
By far the hardest part about setting everything up was to get the new group that I was creating the proper access to do what they needed to do. I've done a bit with permissions, but really, this stuff is complete voodoo. And almost none of the other experienced developers in the IRC knew how to do it. I've done some page permission stuff, and that's also in my tutorial package. But I kept messing up with it, I'm not sure why. Eventually, I got most of the page permissions working, but there was still another problem.
In order to access the file manager and site map in the rich text editor, you need to set task permissions. I'm understanding the syntax that I need for updating permissions, but what the different pieces actually do is a bit fuzzy. So translating what worked for the pages to the task permissions was pretty tricky. It took probably 5-8 hours to actually get it working, but eventually I did.
Yeah, I guess that's a big question. It probably sounds a bit esoteric if you don't program or use concrete5's advanced features much. Basically, I can set up a new user group and a page type with attributes and blocks and make a intricate CRUD application for those page types. All with just a package controller. No single pages, no custom forms, just using the built in API and interfacing with the other packages that I've written.
I think that's pretty huge.
I'll be creating a helper and a custom permission for acessing the page managers for each composer-enabled page type. The helper will let you make the list/search pages and say who can access them. There will also be a dashboard page for making managers from a single form, so that you don't have to use the helper from code.
One of the things that the helper will let you do is specify a few more options for my composer-style page. I want to allow you to specify publish location by attribute value, for one, and to keep that seperate from the page type. Instead, that will be configured relative to the management page.
So you could have an "Article" page type, but then have a bunch of different managers that each cover different types of articles. So maybe one for politics, one for business, one for tech. But then you could set different permissions on each one of those managers, and also change where they are able to publish. That way only one page type is needed to have a really sophisticated news application that allows for very fine grained control of who can do what, and has logical seperation into different sections of the dashboard.
The other thing that I want to be able to specify is a different editing form (package element) for each different manager. So you could make a tabbed interface or have non-attribute checkboxes and radios to make things easier to edit. After that's done, the next step will be to allow you to specify different forms for different users.
So an admin might be able to schedule the room and time for a session in a conference, and approve or deny it. But a speaker could only edit the title, description, etc. They could both use the same listing
Really, I think that's one of the main drawbacks with composer. It basically just loops over everything in order, and makes one super long form that can be pretty ugly and hard to use effectively. In the upcoming 5.7 release will allow you to group things into sets, but it still just shows everything in one big list. I'm hoping to get beyond that and offer a lot more customized experience for site editors.
Overall, it's getting really streamlined. Everything is falling into place, and soon I'll be banging out new apps a couple times a week.
The marketplace sales pretty much doubled last month, and I'm sure they'll do nothing but grow. Another week, and I'll have the rest of the API stuff built. The week after that, I should be able to make a couple more marketplace addons that manage pages. Hopefully, those should be able to get through the PRB pretty quickly, since there won't be much to them at all besides the package controller.
I'm really happy with how things are going with this whole system. I wasn't sure exactly how far I could take it. I just had ideas of where I wanted it to be and what it should do. Each new bit of functionality that I've built for it has fit in exactly as planned.
It makes me really, really optimistic that the things I'm planning to add in will integrate smoothly.