I have had an ongoing litany of issues, particularly relating to the deployment of the completed October site. In fact, it has now taken me nearly as long to get a site successfully deployed as it has taken me to learn October, build the layout and implement it in October CMS. When I say "successfully" I should probably point out that I have in no way succeeded.

I should point out that I prefer to use Heroku and similar PaaS solutions. They work for me, as Heroku has no cost for startup apps, by comparison to a $5 a month cost for Digital Ocean, etc. If October is not compatible with Heroku that's one thing, but I'm not sure why that would be the case and the issues that are occurring seem to be failures on October's part, not Heroku's. I should also not that yes I am aware that October is beta software. This post could be considered beta feedback. This is a severe (completely blocking, I may have to abandon October entirely) issue that is occurring with deployed October instances.

Initially I posted to state my issue - the lack of a composer.json in the installer left me with no way to deploy to Heroku. Attempting to just add a composer.json file and update/deploy from that resulted in fatal errors in composer. In the end I was forced to start again, creating a new local development host from the command line. That all worked fine and I continued with successful development until the project was near complete. I then went to deploy my code to a heroku app.

It is at this point the wheels fell off.

The code I used had a plugin - Rainlabs Blog. This caused a number of nasty errors. Most severely:

RainLab\Blog\Models\Category and October\Rain\Database\Traits\Validation define the same property ($rules) in the composition of RainLab\Blog\Models\Category. However, the definition differs and is considered incompatible. Class was composed

This exception was all I could get to show, and I have posted it to the plugin's forum, with no response so far. Indeed, due to what I would have to describe as a namespace clusterfuck I was unable to find the conflicting files for some time, and even then have not been able to actually resolve the issue. I had installed the plugin by adding the plugin to the project. It was at this point that I found that while you can add a plugin to a project, removing a plugin from a project is not possible. This needs to be possible, as any attempt to update October re-added the plugin, causing the update to fail with the above error.

Weirdly, this error occurred only in the online version of the site. My local version runs 5.4, while heroku appears to be running 5.6RC. An odd choice, to be honest. I tried everything I could think of, deleting the files and db tables manually, git deleting them, reinstalling through the interface or by downloading... everything. In the end the only choice I had was.. simply to give up.

I yet again commandline composer installed the repo, copying over the theme with its content and began a whole new heroku app as well. This time I was careful to keep the plugins out of the repo, and installed it in the production backend.

I have not gotten the above error. I went to the site and had a look around and for the most part it made sense. A missing component on the contact page created an error, so I installed that plugin too and fixed that problem. Then I started browsing around, and found... suddenly everything doesn't work.

Class 'Cms53c7fe72c755c_4288314767Class' not found /app/themes/toughguy/layouts/default.htm line 151

I'm not sure what is causing this, but it appears to be a pre compiled class possibly generated by Twig? I have fixed this error in the past by simply opening up the template and making a trivial change and then saving it again. That seems to work in this case, but as soon as I go to any other page it simply gets the same error. I attempted to resolve this by using October's artisan clear cache command. While this claimed to have cleared a bunch of caches it doesn't seem to have resolved any issues.

If anyone has any actually useful suggestions, or some sort of workflow for October deployment that actually works, I'm all ears. After five days of chasing my tail on deploying an otherwise working project, I'm getting pretty desperate.

Wow, I'm sorry to hear you are having such difficulty.

My suggestion would be to use a cleaner approach:

• Your local copy works great, that's great!
• Set up the remote copy from scratch, I suggest you install using composer for greater control.
• Deploy the /themes folder to set up your theme.
• Deploy any plugins you are using either via the gateway or uploading them manually.
• Deploy the /app/config files
• Deploy the local database to the remote database (overwrite the old database)

Document any errors along the way, this can rule out any issues with deploying cache files and perhaps deploying a corrupt version of the local copy.

Since you are using composer, it is not advised to update using the gateway, instead you should use composer update and php artisan october:update --plugins to update the plugins only from the gateway.

Good luck mate!

Thanks daftspunk. I do have to say, though, that I'm not sure how installing directly on a live server and then committing and deploying bits of an application piecemeal is somehow "cleaner" than the standard approach of working locally, then deploying. I'll give it a try tonight if I'm able.

Ideally, I'd love to know what's actually causing the above issue. Cache? Twig? Composer?

Matt

Last updated 9 years ago

From my experience, the validation trait issue you're experiencing is because you're on an old version of october. Is your server on the latest version of october?

As Flynsarmy says, the errors you have presented suggest something has gone awry. At first glance I would say you are using an older core with a newer plugin and you have deployed cache files.

Class 'Cms53c7fe72c755c_4288314767Class' not found /app/themes/toughguy/layouts/default.htm

Can be fixed by running

php artisan cache:clear

RainLab\Blog\Models\Category and October\Rain\Database\Traits\Validation define the same property ($rules) in the composition of RainLab\Blog\Models\Category. However, the definition differs and is considered incompatible. Class was composed

Can be fixed by running the latest core code, specifically the October Rain library.

Note that the only things you need to deploy are /plugins, /themes, /uploads and /app/config -- we have kept it simple like this. Trying to deploy the whole instance makes sense in theory but in practice things can clearly take a turn for the worst :-)

If you absolutely must deploy everything, then ignore the following:

• app/storage/cache
• app/storage/temp
• app/storage/sessions
• app/storage/meta
• app/storage/twig
• app/storage/....

Well, let's just say the whole app/storage folder.

Last updated 9 years ago

Thank you very much for your help. I actually managed to get it working with your advice, only to find that Heroku doesn't support GD, which makes the whole thing a non-starter for me. Oh well! To Digital Ocean I go.

Saw same types of errors af you mention here. I did a clean install on the live server and the ftp'ed/copied the local pages and plugins as well. This was the only way I could completly remove non-functional plugins from the market/project. Had to re-code quite a bit of configuration and plugin and then do the migration which worked like a charm actually.

Søren

When you say Heroku doesn't support GD, what do you mean?

Just FYI, Heroku does support GD, it just needs to be enabled via the composer.json file.

https://devcenter.heroku.com/articles/php-support#extensions

Hi,

Actually, I've faced to the same problem. However, I found another solution. Firstly, let's analyse the root cause.

In my case, this issue happens on a server which I installed opcache and use its default setting. By using opcache, the PHP code is stored in its optcode caching. So, if any PHP code changes - I need to restart the php-fpm (as I use apache integrated to php-fpm) to make the opcache build with the latest code.

OctoberCMS generates some dynamic classes every time we add new pages or when you click to the clear cache button in the dashboard. So, every time these generated classes created and opcache are not updated, it will cause the issue.

To fix this issue, I suggest you read carefully this article: https://www.scalingphpbook.com/blog/2014/02/14/best-zend-opcache-settings.html

The default settings of opcache set validate_timestamps = 0, so you need to do manual cache reset by resetting apache/ php-fpm. However, if you switch this setting to 1 and set the right revalidate_freq - you will get the opcache build with the latest code => this issue is disappeared :)

I hope this really helps

Last updated 7 years ago

Deployment is an area they just haven't described in enough detail. I literally lost 4 days trying to figure out a way to work locally and deploy quickly because live editing on the server is just not an option.

In the end my buddy and I figured out an approach that deploys the entire repo on each commit (except the env file and storage directory) instead of pushing specific folders.

Try this October CMS and Laravel Forgeguide and see how you get on.

There's no commands to run and it's all automated so as soon as your push to your repo, everything starts. It's pretty seamless once set up.

Last updated 6 years ago