Using C5 for Large Government Sites
Permalink 1 user found helpful
I'm investigating a CMS for several very large government websites. (I mean our sites are large, not our government, but that's another issue.) A few questions perhaps some of you may like to address:
1) How is the security of C5? As a government agency, we're a big target for attacks.
2) How does C5 work with test servers? We currently deploy everything to a test server, make sure it's all approved, then deploy to a production server. Does C5 have easy provisions for doing that without having to duplicate all the revisions on both servers?
3) How does C5 behave with jQuery and similar libraries? We have some complex pages developed in jQuery that we don't want to re-design from scratch, so does C5 allow use of jQuery?
1) How is the security of C5? As a government agency, we're a big target for attacks.
2) How does C5 work with test servers? We currently deploy everything to a test server, make sure it's all approved, then deploy to a production server. Does C5 have easy provisions for doing that without having to duplicate all the revisions on both servers?
3) How does C5 behave with jQuery and similar libraries? We have some complex pages developed in jQuery that we don't want to re-design from scratch, so does C5 allow use of jQuery?
Thanks for the response. In regards to #2 (test server), we can have as many as several dozen pages change every day. With our current static site, it's easy to upload a single page. With C5, is it a big deal to do that many times a day? Or would I need to have a daily release rather than our current release-every-few-minutes plan?
I see what you're saying about #2...I was thinking you meant just initial stage to launch - not a simultaneously running development and production server. I've never actually run such an environment, so I'm not sure what the best method would be. As far as I know, there's nothing in C5 that would automate this for you, but it seems that you could still create a custom server process (cron job or something) that would copy the DB and files from the dev server to the production server. I'm not very familiar with this process though, so I don't know what the best direction would be...
There are several ways to do this that don't involve a test server. Concrete5 has a page approval process. Someone could create or update a page. After it is done, the page can wait for approval from another person. That way you can see that the page is correct before it is released.
The second way is to create or update a page, and after it is done, set the page to be released at a particular time. For example, maybe you want page updates to happen at noon.
The third way is to edit and preview the changes as much as you want until it is complete and then save the page. The page goes live at the moment it is saved. If something catastrophic would happen, you can easily revert to the previous version of the page.
The second way is to create or update a page, and after it is done, set the page to be released at a particular time. For example, maybe you want page updates to happen at noon.
The third way is to edit and preview the changes as much as you want until it is complete and then save the page. The page goes live at the moment it is saved. If something catastrophic would happen, you can easily revert to the previous version of the page.
Thanks Mose. I think those methods would work for most text pages. But a page that requires extensive testing before it can be released would need to reside on a dev server first before being moved to the prod server. So that's what I'm trying to find out - how easy is it to move stuff from a dev server to a prod server in a C5 environment.
That could be a little complicated, and it's not an issue specific to Concrete5. This would be a problem for any CMS. A CMS doesn't lend itself well to moving pieces between servers. The content parts of a page are stored in a database. The page itself consists of the physical files that make up the page and code files called to create or fill portions of the page.
In the most simple case, you can create or update a file on the test server and move it to the appropriate directory on the production server.
In the most complicated scenario, you have an entire package of files plus data in the database. The data in the database would have to be extracted to a file and packaged with all of the supporting files. The package can be moved to the production server and installed through the web interface (plus run a routine that loads the data into the database).
The specific answer depends on what kind of changes are being made on the test server. If it is something consistent that is done often, you could write a script to copy the changed files from the test server to the production server.
In the most simple case, you can create or update a file on the test server and move it to the appropriate directory on the production server.
In the most complicated scenario, you have an entire package of files plus data in the database. The data in the database would have to be extracted to a file and packaged with all of the supporting files. The package can be moved to the production server and installed through the web interface (plus run a routine that loads the data into the database).
The specific answer depends on what kind of changes are being made on the test server. If it is something consistent that is done often, you could write a script to copy the changed files from the test server to the production server.
We typically run a development stage and a content stage on our bigger projects. On the content stage, the DB is never wiped, the client owns it from as early as we can get them in on. On the development stage the content is trash, developers own it to test what they're working on and they will routinely take a snapshot of the live content to get a better sense of the real content environment.
This would work well for building complicated single pages in your situation.
It is not multi-tier workflow approval like something like TeamSite would do.
If you need that type of thinking, my suggestion would be add a custom attribute to every page for approval level and then do an approval UI in the dashboard that manages who gets to approve what. We actually just helped build something along these lines for Clear Wireless that is transitioning over to concrete5 and it is the perfect solution to that problem of multiple levels of approval.
Regarding security, its secure as any well written software. New features come out, small vulnerabilities are discovered and resolved quickly.
Regarding performance, should be fine. Particularly version 5.4 with the zend caching layer is speedy speedy speedy..
feel free to private message me with any questions or concerns if you'd like.
best
This would work well for building complicated single pages in your situation.
It is not multi-tier workflow approval like something like TeamSite would do.
If you need that type of thinking, my suggestion would be add a custom attribute to every page for approval level and then do an approval UI in the dashboard that manages who gets to approve what. We actually just helped build something along these lines for Clear Wireless that is transitioning over to concrete5 and it is the perfect solution to that problem of multiple levels of approval.
Regarding security, its secure as any well written software. New features come out, small vulnerabilities are discovered and resolved quickly.
Regarding performance, should be fine. Particularly version 5.4 with the zend caching layer is speedy speedy speedy..
feel free to private message me with any questions or concerns if you'd like.
best
1. Very good I would say. I am using C5 to run a university web site that averages around 12k visits/day. Have had no issues at all with regard to security, and we have recently had our server audited to check for XSS and other security vulnerabilities. No issues.
2. I do many freelance sites this way. Typically my process works as follows: 1. Copy over DB and files. 2. Change config/site.php to reflect new server settings. 3. Clear C5 built-in cache. I have never had any issues with this.
3. Perfectly! C5 uses jQuery all the time. It is part of the core of the CMS. Version 5.3.3.1 (latest stable version) used jquery 1.3 I believe, but the next release of C5 (5.4) will be using jQuery 1.4.
Sounds like C5 could be a good fit for you.