I’m a longtime web developer with things like Ruby on Rails and Wordpress, but new to Concrete CMS. I’ve inherited a 5.7 project.
If I create a single page on my development setup (created with docker), how do I get that same page in production?
I’m using git, and so code (the single page view at application/single_pages/mypage.php and controller at application/controllers/single_page/mypage.php) make it to production no problem. But unless I’m mistaken, I also have to manually go into the Dashboard at https://example.com/index.php/dashboard/pages/single and add a route manually for “mypage”, otherwise going to https://example.com/mypage will result in a 404.
You are coming up against a specific instance of a problem that has existed forever.
Its easy to copy code between sites. But copying settings that are held in the database is all or nothing.
Personally I always develop in packages. Then use the package controller install method to run code to add the single page. You can also use an XML file in the package install to declare single pages to add (and blocks, attributes, and anything else). That takes care of code and installing single pages, blocks, etc.
That still doesn’t facilitate generally pushing updated content from stage to live. You unfortunately need to plan what needs to be edited on stage (for testing) and then edited again on live, and what content you can write directly on live.
In most cases, once a site is live new content is consequently edited directly on the live site and workflows/permissions are then used to prevent visitors from seeing content before it is ready.
1 Like
Ah. Thanks for the knowledge on packages. I’ll read up more. It sounds like that might also handle the idea of “migrations” that I’m used to. Meaning that if I use a package to add a single page, and then I switch to a different git branch to work on something else, that single page will be removed. I hope so!
Uninstalling a package will also remove any blocks, pages etc installed by the package.
For changes between versions of a package, you would need to write your migration code into the package’s update method.
1 Like
There are plenty of free packages in the marketplace you can use for ideas on getting started. Pick one or two from established developers that are fairly recent.
There are also package starter boilerplates in various developers’ accounts on GitHub. Though take care, some could be very out of date.
Ooh, good to know. Would you happen to know any references to writing quality migration code? Are there best practices/standards to follow, perhaps by the community? I intend to read the official Concrete CMS docs on packges, but if you know a great 3rd party reference where all the cool kids hang out, that’s good to know.
Good idea on looking at examples. When I’ve found myself at the marketplace (googling for things related to this project, I often find myself in there, as I try to unravel whether the code I’m working with is core or some add-on), I’ve found it hard to tell if code is popular/good/recommended, or old/outdated/untrusted/not-quality. Do you have one or two off the top of your head? This project is using something called Chisel, I might look at that one.
Chisel was a well thought out tool for creating data classes, but its been 6 years since it was last updated, so is unlikely to reflect current best practice or core API use. It is not flagged as v9 compatible, but may well work with some limitations as it is primarily a dashboard tool.
I suggest sorting the marketplace addon or theme lists by ‘most recent’ and seeing who/what crops up. Every developer has their own preferences within the scope of current good practice, so you could look at a few and see what approaches fit in with your own style preferences. For example, some developers prefer very pure Laravel-ish structure. Others are more traditional. But all are within a general scope of Concrete good practice.
There is also a page somewhere on the Concrete.cms or .org sites that lists various other (non-marketplace) code, such as Community Store. You will need to hunt through the menus to find the page.
Thanks for mentioning that Chisel is old. I think the site I’m using was built originally in 2016. I don’t need version 9 compatability because I’m on version 7 (5.7) I think.
It can be tough to know what’s out of date with Concrete. When I look at the docs for assets, the video linked is from 2013. Assets Overview
Thanks for your help navigating all this!
Chances are, a site build on 5.7 will not be even php7 compatible, let alone php8. So you could have lurking hosting and security issues.
Before getting too far, I would create new a dev clone of the site and experiment updating to 5.7.13 then 8.5.12 (it could involve a fair amount of code updating).
Very little code is maintained that far back and best practices have moved on a long way, so my thoughts above could be leading you into code that is not back compatible to 5.7 and maybe you need to be that far back to use Chisel. You will need to weigh up the alternatives.