I’m just guessing, but I think it’s more likely that you’ll see versioning for individual pages first (possibly like WordPress drafts). Then versioning for templates, chunks and possibly other objects. There is already some work being done in this area.
There is also the Provisioner add-on, which allows you to synch. one site with another. Generally, a localhost (e.g. XAMPP) site is used as the staging/test site, and when you like it, you send the changes to a remote site. I don’t know any reason why it couldn’t be used with two remote sites instead to do what you’re suggesting.
-
☆ A M B ☆
- 2,475 Posts
I’ve encountered a fair amount of variation in different projects, so I don’t yet have a good "one-size-fits-all" solution for dev/prod deployment for MODx sites, so I don’t know if something will be released that fits everyone’s needs. I think Bob’s right: versioning will probably be first.
Because MODx is a web app, the general principles apply of dumping the database and zipping up the files, but the caching/multisite features make for some more complex caveats. I think it’s critical that the basic manager do more thorough permission checking in everyday operation because the permissions are usually what get bombed when moving a site, and currently, only the setup process does a thorough check of them.
How does Silverlight handle this?
Actually, I don’t have much experience with SilverStripe so I was basing my comment off of what the other poster said. In my custom CMS implementation though it works this way:
1. 2 databases (one can be local the other remote, but usually both are on the same server)
2. 2 separate sites (staging and LIVE)
3. 2 separate configs (staging and LIVE) in order to handle paths, etc.
3. as you browse the staging site, you can edit any page, check-in, or publish. There is a bar across the top that tells you you are on the staging site.
4. things like components (dynamic code) are developed and tested on the staging site and then pushed to the LIVE site/directories when a page that needs them is ready to be published.
So you can see it’s much more than just versioning or drafts. You actually have two distinct sites. As far as "permissions," not sure if you are talking about file permissions or rights, but it’s set up to handle most of that automatically once the initial directory permissions have been set because some directories need to be writeable.
Anyhow, there are so many different approaches one could take with this and what works well for one developer/company, may not work well for another and I guess that’s why so many people have created their own custom cms solutions...but then they are proprietary, are a pain to keep updating as "best practices" change, and you aren’t able to collaborate with a community.
-
☆ A M B ☆
- 2,475 Posts
Yeah, there are many approaches.
I was referring to file permissions -- those are harder to control because they are dependent on the server and not on the application. E.g. on my dev server I have Apache running as user "dev" or something, so the files need to be owned by the dev group and have permissions of 775. But that user/group doesn’t exist on prod, so when I copy over the files, the owner/group gets messed up... the owner needs to be changed, and permissions need to be adjusted to 755. Things like that are really hard to standardize because it’s outside the scope of the app.
Yep, I agree. One problem with any open source project is that you kind of have to be all things to all people to provide flexibility with the end result that sometimes the project and code just becomes bloated. Think WordPress as a classic example. That’s why I think a lot of people just end up rolling their own code/CMS so they can have complete control and reduce the bloat...but that’s a daunting thing for one or two developers or even an entire organization.
-
☆ A M B ☆
- 2,475 Posts
Well said. I can only imagine how hard it to juggle a zillion contributions from the masses and still manage to steer the ship of a big open source project. To its credit, I think MODx does a great job -- the architecture allows for good separation of power. WordPress is a bit of a confused Neanderthal under the hood... you can make it do things, but it’s just cludgy as @#%! if you need to do any heavy lifting. After working on some large WordPress projects, I’m so glad to have few MODx ones in my queue... it’s soooo much easier to extend.
Anyhow, the devs have been really great about fielding questions/suggestions re new features. It’s probably worth writing up a feature request over at bugs.modx.com. Architecturally, all of this should be possible via variations on the config file...
Sounds good. I’ve got a friend who absolutely loves modx, so I’m eager to test it out on a real world project.
