I added a new theme to ghost cms, It displays in the listing on my local machine, but on my heroku instance I cant see it in the list of available themes.
Is there a way to restart Ghost in heroku, or a way of forcing it to appear? Ive tried restarting the dynos, and redeploying to no avail.
How did you install the theme? The instructions make it look like this involves dropping files into a directory (either using the admin UI or manually).
Heroku's ephemeral filesystem isn't compatible with that:
Each dyno gets its own ephemeral filesystem, with a fresh copy of the most recently deployed code. During the dyno’s lifetime its running processes can use the filesystem as a temporary scratchpad, but no files that are written are visible to processes in any other dyno and any files written will be discarded the moment the dyno is stopped or restarted. For example, this occurs any time a dyno is replaced due to application deployment and approximately once a day as part of normal dyno management.
Any changes you make to the filesystem will be lost when the dyno restarts, which happens at least once per day. (Maybe counter-intuitively, restarting your dyno will have the opposite effect from what you want.)
You'll have to commit the theme files to your Git repository and deploy the new code to Heroku. In addition to making the change persist across dyno restarts, this also makes the new theme available to all dynos (if you scale beyond one).
#chris I solved the issue, it turns out my content path in config.production.json was wrong. It wasnt looking in the right place for the themes
it was
"paths": {
"contentPath": "content/"
},
and it needed to be
"paths": {
"contentPath": "content"
},
Related
I would like to have my app rebuilt and redeployed once per day. The reason for this is that I am using Jekyll and I display 'upcoming events'. I use LiquidScript to determine which events are 'upcoming', which ones are already in the past and which ones are too far in the future. But without redeploying, nothing on the site changes, even if I rebuild it. That's why I would like a solution to this, and one that can be made automatic with scheduler.
EDIT: Zappa does not use EC2 and not Beanstalk, but Amazon Api Services.
So probably there ist no way.
I have a question for Zappa EC2 Serverless Services.
Launching zappa update dev creates one Zip-File and uploads this. Because my upload is slow, it would be great to have ability to upload only changed files, especially in the beginning (config files etc) of a project. Every single file change needs 5 minutes.
Yup. There is no way.
I had the same problem (slow home upload) and ~solved it so that I'm deploying through a CI system (that has a much much faster upload).
If you are deploying an open source app you can use Circle CI's free tier for open source or for closed source you can take advantage of Gitlab's free CI offering.
Here is my Circle CI config file for my open source project.
It took me 2-3 minutes to just upload .zip from my local computer, now it takes less than a minute to run all the tests and deploy.
For me, the main advantage is that I don't have to nervously watch shell for the next few minutes and can just continue with my work.
We've recently launched a new website in Azure (i.e. Azure Websites) and as is typical with new launches we've had to deploy a few tweaks to fix minor issues shortly after launch.
We want to use Slots in the long run but this is not possible at the moment. Hence we are deploying to the live site. It's a fairly busy site with a good amount of traffic and obviously want to keep downtime to am minimum.
We are using Visual Studio to publish file changes to Azure but have noticed that even if we publish a relatively insignificant single file the whole site goes down and struggles to come back up. I was assuming that publishing a single file would literally just replace that file on the file system but it's behaving more like it recycles the application pool (or Azure equivalent) for the site. The type of files I've been publishing have been Razor views, hence would not typically cause a recycle.
Does anyone know what actually happens under the hood of VS Publish and if there is a way to avoid this happening?
Thanks.
I just tried this using a basically clean new MVC app (https://github.com/KuduApps/Dev14_Net46_Mvc5), and I did not see this behavior. The Index.html view has a hit count based on a static, which would tell us if the app or the page got restarted (or if that specific page got recompiled).
Then the test is to publish it, make a change to some other view (about.cshtml), and publish again. WHen doing this and hitting Index.cshtml, the count keeps going up, and there is minimal slowdown.
If you see it getting restarted after a view change, I suggest using Kudu Console to look at the files in site\wwwroot before/after the publish, and check what has a newer timestamp (e.g. check web.config, bin folder, ...).
Our production Liferay instance absolutely refuses to deploy my latest theme. Something is preventing it from displaying my latest CSS changes. Unfortunately, there are NO log errors and no Firebug Console errors, so it's been a real headache to diagnose. I just get a really ugly plain page with links and no styles applied.
I have tried everything I can think of to fix this.
Undeploy/redeploy theme
restart the Glassfish container
use Liferay Server Administration page to "Clear content cached across this JVM", "Clear database cache", "Verify Database plugins", etc.
undeploy, restart, redeploy
undeploy, delete leftover files/folders pertaining to the theme in 'applications' folder, restart container, redeploy
clear my browser cache
try a different browser
many more combinations of the above. You get the idea.
Last night I reached the boiling point because my theme deployed and displayed in our test environments without issue, but didn't work in production. The only thing that was different is that I wasn't using
include-and-override=portal-developer.properties
in my portal-ext.properties file.
I took a gamble and added this line to my production portal-ext.properties and restarted the production server. My theme now displays without a problem.
The file portal-developer.properties only appears to contain the following properties:
theme.css.fast.load=false
theme.images.fast.load=false
javascript.fast.load=true
javascript.log.enabled=false
layout.template.cache.enabled=false
browser.launcher.url=
combo.check.timestamp=true
freemarker.engine.cache.storage=soft:1
freemarker.engine.modification.check.interval=0
openoffice.cache.enabled=false
velocity.engine.resource.manager.cache.enabled=false
com.liferay.portal.servlet.filters.cache.CacheFilter=false
com.liferay.portal.servlet.filters.etag.ETagFilter=false
com.liferay.portal.servlet.filters.header.HeaderFilter=false
com.liferay.portal.servlet.filters.themepreview.ThemePreviewFilter=true
So, finally, my question is, am I merely trading a slight performance boost for a massively easier deployment experience?
Or are there more serious concerns to loading this file in a production environment?
Thanks in advance for the input!
Ben
You'll get a really bad performance with that portal-ext.properties. That configuration is only intended to be used in development environments.
If you delete the css/.sass_cache directory on your deployed theme you'll see your css changes and you'll be able to use a different portal-ext.properties on production environment.
http://issues.liferay.com/browse/LPS-26939
Regards
I've been experiencing this very odd problem lately in Heroku.
I develop and test locally, then I push the changes to Heroku. Even though the files pushed have been changed (and Heroku does recognize it and push the new files), when I look at the exact webpage on Heroku, it behaves as though it was still using the old version of the file that I just pushed.
When I see the HTML source in firebug, I can actually confirm that the old file is being used.
I've tried using git push -f to "force" the git push, but no luck
any ideas??
Try heroku restart to force a restart of all the dynos. I'm not positive but I've seen indications like this that they tend to "lazy restart" the dynos and workers after a push. If you want to guarantee all workers and dynos are working off the latest pushed code, do a restart after your push.
I know this is old, but I just recently had this problem, turned out it was just my cache. If you hit ctrl + F5 it hard refreshes the page and the cache. Worked in my case after searching everywhere.
Experienced same problem too, so checked the repo files by running heroku git:clone -a my-app cloned the files currently in heroku master, and confirmed that the files in repo are the updated version. Hence, the newer files are uploaded correctly but is not being reflected by heroku. Hence I ran heroku restart and waited a long time, like 3 or 4 hours, and problem solved, heroku started running the new files.
Not exactly sure if heroku restart or simply waiting for 4 hours solved the problem, and I doubt I needed to wait 4 hours for heroku to reflect newer repo.
However, I think, after deploying to the same master branch git push heroku master, heroku needs some time to reflect the newer files, hence the switch to newer files will not be instant, it takes time.
Hope this helps anyone else experiencing the same problem.