[Suggestion] Upgrade process about canvas HOT 27 CLOSED

@reliq Awesome, looking forward to seeing what you come up with!

from canvas.

Great question @foxted. Still working on figuring that one out. If you have any ideas or thoughts on it, I'd love to hear it.

from canvas.

I was thinking isolating Canvas-specific files into it's own folder, kind of like what Laravel Spark does. With a console command to update to the latest version.

from canvas.

@foxted I've never actually used Spark before. A command should be easy enough to create. What do you think, a new command for each version upgrade? Or just large upgrades?

from canvas.

Realistically people are unlikely to amend the backend so you'd just publish the backend assets again using a command which is pretty easy. The only place it becomes tricky is when a user has altered the front end section.

from canvas.

@talv86 Yeah I'm a little stumped right now determining how to make this happen. Any expertise you have here would be awesome.

from canvas.

gah i wrote a response to this this morning looks like i forgot to press post :(

one of the first things i did when forking Easel was to allow users to create a custom layout for their post pages meaning the originals could stay in tact and consequently all publish events can overwrite them without me worrying about them being destructive.

Spark actually has a mechanism that will only publish files that haven't been changed, its something i looked into originally but didn't quite get it to work, i figured i'd come back to it at some point since i wanted to actually get on with the core feature development.

from canvas.

So the journey to create an upgrade process/route continues. Thanks to some great work by @foxted , the assets are very modularized now with 2 specific files for users to write their own styles and child-theme elements. Those two files should be able to port over to a new installation of Canvas, or really just be protected during an upgrade process. With the new Tools section included now, users can also export the entirety of the database as well as their uploads directory, essentially saving all everything they've ever done to their instance of Canvas, unless they've touched the core files. With that being said, do you guys have any suggestion on how we proceed? @talv86

from canvas.

As others have suggested, the best way to probably do this is to keep canvas stuff in it's own folder and allow overrides by publishing vendor views to the app's /resources/views/vendor/canvas folder.

That way you can upgrade that folder without issue and it just works for the user. If they have published/modified any of the files they can compare their changes to the source to update manually.

from canvas.

@tomschlick Thanks for the input! Unfortunately, I'm still perhaps not envisioning this correctly. Not quite sure how I could take Canvas and do with it what everyone is suggesting here. Would you care to make a PR of the suggested changes?

from canvas.

Sure thing, I'll take another look at how spark is doing it and make a pr to replicate the process here.

from canvas.

That would be absolutely fantastic. Thanks so much for the help @tomschlick!

UPDATE: Anything you need me to do to help with this process @tomschlick?

from canvas.

I'm wondering why the upgrade proces as it is described is that complex ? The (simple) user needs to find out the database commands himself to perform the database-actions. I'm looking for a way to make the upgrade-process a littlebit more 'scriptable', but the "backup" mechanism is imho an extreme way of upgrading (it's actually re-installing).

Wouldn't it be an idea to do this the "Laravel"-way by actually making the users use the migrations ? Then you don't have to worry about the underlaying storage/db solution that the user chose to implement. You guys have been using the migrations consequently, so there's imho no problem here.

The upgrade process that could work (i assume every user has shell access to the Canvas root he'll be upgrading) at least, for me it's working well for the past weeks. But this upgrade-process only works if you cloned the git repos (people who used packagist or downloaded the zip cannot invoke the git commands):

> cd <canvasroot>
> php artisan down
> git pull
> git checkout tags/v2.1.12   # latest tag , of course
> composer install
> yarn
> php artisan migrate
> php artisan up

The only thing i think i'm missing here is the update of the settings-table.

Right now, i'm running a query on my db to workaround this :

> mysql> update settings set setting_value = 'v2.1.12' where setting_name='canvas_version';

To get rid of this issue i guess you have a few options:

1. you could add an artisan command for upgrading, which updates the canvas_version setting. But to get there , we need to find a way to dertermine which version is installed for each type of installation method (currently git clone, git download or packagist);
2. add an migration for each tagged version to update the canvas_version-setting (probably the simplest method for now ?);
3. other idea's???

Can you think of anything that i'm missing here ?

Curious how you guys think about this ...

Kind regards,

Mark

from canvas.

@mhuijser I totally agree with you.

Imho an upgrade command like php artisan canvas:update like laravel spark would be nice.

In this update command we could upgrade the setting_value of the canvas_version to the latest value. Also it would be a place where we could call other commands to support the update process. Maybe we could retrieve an argument version with the release tag and could use this to determine what we 've to change. But still I guess we've to provide individual update solutions for some versions?!

from canvas.

@mhuijser I appreciate your post here. The issues you brought up are the ones making this process difficult, but I like how you detailed out a potential process, one that you've been using yourself as of late. At the end of the day, I'd really like this to be a one-click upgrade, or a one-command script using Artisan. I'll dig more into what you've written here, but am really excited to see this as potentially taking care of our upgrade issue.

from canvas.

After chatting a little bit with Eric Barnes, he told me how he solved this problem of upgrading with his own project WardrobeCMS.

"For wardrobe we moved the core to it’s own composer package. Then the main download is just laravel + routes + views."

So, removing the core out of Canvas and keeping it in a separate repository is something I'd be willing to do, but don't see at the moment how it all comes together. If anyone else out there is quite familiar with Laravel package creation and thinks they can attempt this, let me know.

from canvas.

We could take queues from Flarum. Similar to WardrobeCMS, what they do is have the separate repositories under an organization account. So the app pulls the core package via composer and voilà!

@austintoddj I'd make an attempt to migrate the core files.

from canvas.

@austintoddj what do you think of the organization idea?

from canvas.

@reliq Just created a new repo called Easel that will hold the core code of Canvas. Will that be enough for you to begin working with?

from canvas.

As other suggested, it might be easier to manage in the long run via an organization. If we are splitting repos, now would be the time to do it so urls only change once...

"canvas" & "canvascms" are both taken... so maybe something like "canvas-publishing"?

from canvas.

@tomschlick Good advice. Let me think about that for a little bit. I'll get back to you.

I was actually under the impression that it would require payment for creating an organization, but it looks like it's free to make one with public repos? 👍

If that's the case, I'm all for creating an organization. Now, the name is the key.... canvas-publishing is ok, just a little lengthy. Any more ideas?

from canvas.

Yes that's the idea @tomschlick.

Here are a few suggestions @austintoddj:

• lacanvas
• canvaspub
• canvaspress
• canvasphp
• writecanvas
• pencanvas
• inkcanvas
• canvasink
• canvasinc

from canvas.

Why not just canvas-cms? It's descriptive and doesn't change the name of the project at all, all dependency packages could than be named similarly canvas-x.

from canvas.

@talvbansal I mean even that could work.

Can we get a decision on this?

from canvas.

Thanks for the valuable input, but I'd like to keep it outside an organization. So the repos will remain as-is, with Easel holding the core framework of Canvas to ensure easier upgrades.

If anyone wants to fork the repos and begin that process, I'd love to see what you come up with.

from canvas.

@austintoddj OK. Please add a file to the easel repo. I'll fork it after.

from canvas.

Resolved on the develop branch of Canvas and Easel. Will be made available in the next release.

from canvas.