-
-
Notifications
You must be signed in to change notification settings - Fork 517
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Suggestion] Upgrade process #95
Comments
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. |
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. |
@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? |
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. |
@talv86 Yeah I'm a little stumped right now determining how to make this happen. Any expertise you have here would be awesome. |
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. |
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 |
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. |
@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? |
Sure thing, I'll take another look at how spark is doing it and make a pr to replicate the process here. |
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? |
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):
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 :
To get rid of this issue i guess you have a few options:
Can you think of anything that i'm missing here ? Curious how you guys think about this ... Kind regards, Mark |
@mhuijser I totally agree with you. Imho an upgrade command like In this update command we could upgrade the |
@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. |
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. |
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. |
@reliq Awesome, looking forward to seeing what you come up with! |
@austintoddj what do you think of the organization idea? |
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"? |
@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.... |
Yes that's the idea @tomschlick. Here are a few suggestions @austintoddj:
|
Why not just |
@talvbansal I mean even that could work. Can we get a decision on this? |
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. |
@austintoddj OK. Please add a file to the easel repo. I'll fork it after. |
What is the suggested update process? If none, how would you like to go to update a project created with Canvas?
The text was updated successfully, but these errors were encountered: