Often the text/html for editable sections of a site is stored in a DB. With October it is often file based which seems to cause some problems related to VCS.

ie. Let's say I create a full site with dummy text sections that a client can later edit. I will have those dummy text sections as "content" types and have them under version control. If the client goes onto the production site and modifies the "content" via the CMS then it will cause an error the next time I try to deploy via a 'git pull' on the server.

Should I not allow the client access to the CMS and come up with my own way of editing those sections? What's the best practice?

Last updated 10 years ago

the way I see it you have two options.

1. Don't give your client access to the back-end (or only give an admin that access) and create a separate back-end where clients are able to edit the files.
2. Create a plugin that stores the content in a database and give clients a way of editing and adding them.

As for best practices, I have no idea.

@jmayhak943 i've written plugin simple pages with database stored content and wysiwyg, i'll wait to moderate this plugin

Interesting question, and I'd love a community response. Here's my take on it.

• Do all site development locally
• Deploy to production server, give client access.

When you're doing additional plugin work, do that locally on a feature branch. If you're using git or mercurial then that will work well, as branching is cheap. When the feature branch is working on your local machine:

• Lock the client out of the production site
• Commit all changed files on the production server
• Pull those changes down to your local server
• Merge in your feature branch
• Make sure it still works, and push it to the production server
• Test on the production server (obviously!)
• Allow your client access to the production site again.

That's just off the top of my head, how I'd do it. To be honest, I've had some trouble with changes getting lost when merging branches ... so it's entirely possible I'm doing things in a non-optimal (read: wrong) way.

Actually, I think I have a better way. The above method is for new features or plugins, not individual pages.

Have a staging site where all the changes get made. And create a plugin that allows for timed publishing. When it needs to go live, the plugin will commit and push the changed html file only, which if a hook is set up will auto push that change to the production server.

Of course, if there are any DB changes to go with the HTML changes then you'd be out of sync with this. So you may want to actually commit and push the entire site and create a migration script to run on the production server to update the DB at the same time .... hmmm. I don't think either idea is "best practise" though, as I can personally see a few flaws in both.

I have been struggling with how to get a good flow for this all day... I work with separate copy-writers, so I am actively developing the site on my local box, while they have access to the "Staging area" on the server (through the CMS) to update content.

So I want to be able to:

1. pull in the changes from staging -> local (so I have the updated content to work with), and
2. push from local -> staging (to update the staging area, and merge any conflicts)

I have tried a couple approaches that didn't work (with hooks) -- but I am not good with Git, so I am completely stuck with how to do this properly.

Last updated 10 years ago

@jason

Have you had a look at Coda 2? It's an all-in-one FTP manager & file editor, that can also track updated files from you local machine & publish them to your server for you, along with being able to down-publish any files you'd like - I use it for managing all my file-based (non-database) controlled sites.

Interesting, so does that suggest file-based CMS's aren't actually a good fit with git-push deploy? It does say "easily manage changes and deploy updates with Git" right on the OctoberCMS home page, so I kind of was assuming there was some typical workflow that came along with this...

It feels a bit weird to go back to using FTP to manage the website.

What about something where the live files auto-commit, and are in a different branch that I can merge back in locally?

I posted a stackoverflow question about this here: http://stackoverflow.com/questions/23850900/syncing-dev-production-with-git-with-a-file-based-cms

You can link Coda 2 with Git and also use it to manage your files through the desktop app - Coda 2. As I mentioned, it keeps track of updated files so you only publish the changes. I don't think there's an automated way of doing this yet, it's a manual process as far as I know (maybe different with Git & iCloud), but there are some FTP clients that you can use to assign a "watch folder" to do the automatic uploads for you if you need that functionality - Yummy FTP - although there probably are better ways to do this.

I know FTP is like taking a step backwards, but I've never had any issues with the above process using Coda 2. If you're not good with Git and just want a quick & easy way of deploying local files to server & back again, then I recommend Coda 2. I've never personally used it with Git, but I know it has the functionality to manage it.

EDIT: just read that Coda 2.5 (out soon) will have support for save & auto-publish to speed up workflow. Apparently, you can use it with Git quite successfully, using Git as your VCS and Coda as your editor and bridge between the two.

Last updated 10 years ago

Thanks for the info -- I might just end up giving Coda 2 a shot again for this (I tried it before but it was a bit too cumbersome for me).

The current thing I am doing is running gitwatch on my live server, which auto-commits changes to files and pushes them to github. I have it name the commit:

[auto] CMS edits on 2014-05-25 19:02:10

Then I merge those changes in locally... and "git push" to deploy local changes. It's working decently so far. Would be interested to hear some other setups too.

A related question, when it auto-commits, it includes various changes in storage files, ie:

app/storage/cache
app/storage/sessions 

is it OK to .gitignore them? It would be a lot cleaner to just commit the one file being changes. If I do ignore them, would it maybe be a good practice to

php artisan cache:clear

after each "git push"? Or unnecessary?

Last updated 10 years ago

As I see it the problem is that October stores code and content in the same file(s). As far as I can see this is problematic when using VCS e.g. Git because it's not really possible to only commit the code part of the files. When deploying to a production environment content gets overwritten. Wouldn't it be nice to store page content in the database? Of course this would be a major change in October CMS, because it seems like the marketing feature. Would it be possible to write a plugin which completely changes how content gets stored?

Nice thread - good to see I am not the only one strugeling with this.

Some thoughts:

• One (impractical) way of doing it without having to redesign October would be to add page cotents via "partials" and then ignore them during version control/git.

• FTP is pretty hard to keep updated locally since the sync-functions are not using hash but rather time-stamps

• FTP is useful for shared hosting (just learned mine dosent support SSH/CLI)

• I also only read the last part of "This makes the website themes completely manageable with Content Version Systems like Git or SVN." - yes, the Themes [layout] are SVN friendly. Plugin and contents not much so.

There are already a few WYSIWYG plugins that store the content in the DB. I think. I haven't used them as I've always imagined that October is trying to be a file based CMS, in that the content is storeable in a VCS. Which, as you said @thasmo, is the marketing feature. From my point of view of course.

Which does leave the big issue of how to store plugin information, if you do end up wanting to store everything in a VCS. The obvious solution is migrations, but comparing versions of DB tables doesn't sound like something I could whip up overnight :)

The other solution, is to develop locally on a branch and push/pull to a cloud repo (github, bitbucket, etc). Whenever you're ready to push a local change, get live to commit the master branch and push it to github. Pull that down locally and merge your branch git merge --no-ff master local-branch . If you're after more information around that, have a look at gitflow as it has some great ideas around branching.

This thread's given me a few ideas to think about, that's for sure!

I'm at a loss for expression, but I'll try to discuss with you guys ))

May be it's not closely related to point of this thread, but it's solution of my problem.

I'm developing with local server - bitbucket - production server. In my case production server doesn't support composer, so I'm using git for transfering vendor files. As I noticed, only theme you are current using can be modified from web gui on production. So I decided to create two repo for it. First is my whole project, second - is my theme. I'm using git submodule to include theme to my project.

I can update project without any conflicts. As to theme repo I use benfreke's solution.

Last updated 10 years ago

Oooh, git submodule is not something I know about. But it might answer a few questions I've got in my head. That sounds like a very workable solution to @adis.osmonov, I might have to steal some ideas from it :)

Can't you setup a git repo inside your theme folder so it is separate from everything else?

http://willandorla.com/will/2011/01/convert-folder-into-git-submodule/ - it's related to what I've talked.

So here is how I'm going to handle this:

• deploy to server (I will be using dokku-alt: https://github.com/dokku-alt/dokku-alt). Lets say I am deployed to /var/www/app
• When I deploy, This happens (simple bash script will do this):
  • I have my git repo pull to /tmp/gitclone
  • remove my themes folder from the app rm -rf /var/www/app/themes
  • symlink the /tmp/gitrepo/themes to my web folder ln -s /tmp/gitclone/themes /var/www/app/themes. This is done because my /var/www/app folder is not a git repo, but even if it was, I want my themes folder to be whatever branch I want.
  • checkout the content branch of my repo git checkout AutoCmsSave && git pull origin AutoCmsSave
• use an octobercms plugin (not yet written) that will auto commit my themes folder to a git branch and/or popup in CMS backend to add commit messages.

When I need to make develoment changes, I pull my AutoCmsSave branch, merge with master (this will give the me most up-to-date CMS content). Make changes, push changes to AutoCmsSave brahcn, push to deploy.

The only way I could think to do this w/o forcing me to login to the server (using dockerfiles, so I don't want to do this) and pushing CMS changes. I figured it must be automated.

Last updated 10 years ago

Jeeze, I've really been sitting on the idea of my VCS and the flat file CMS aspect of October for a while now. I'm still a bit too nervous to use OctoberCMS on a live site though because of this. While there are a bunch of great suggestions here, I'm starting to think that maybe just a plugin that acts identical to the "content" section but instead stores it in the database might just be the best solution.

Right now for example, the Blog works absolutely perfectly with a client and using Git. The posts/content are stored 100% in the database though. I'm really beginning to think that site content will need to be as well in order for this CMS to replace something like WordPress.

For short-term, the path that I'm leaning towards is to .gitignore the theme/content directory and in a sense it would just act like database content as it would only live on the production server. It's still a bit worrisome to do that though because that means all editable content I will need to place within the content directory AND if the client ever screws up the content, there will be no backup of it whatsoever since it's completely removed from the repo entirely.

It's been 4 months since this thread has been commented on and I really think this discussion has been immensely useful and should continue.

For those who are actually seriously using OctoberCMS with clients and utilizing the CMS aspect of it, how are you going about doing that now?

Last updated 9 years ago

Use the static pages plugin http://octobercms.com/plugin/rainlab-pages