If I change files in the src/ or, for example, src/css/ folder, the server regenerates the site automatically. However, if I modify code in src/morea/, there's no regeneration. Any idea what I've done wrong? Here is my site.
Short answer: Unfortunately, you've done nothing wrong, that is now the "correct" behavior in Jekyll.
Long answer: Morea sites tell Jekyll in the _config.yml file to exclude the morea/ directory from normal processing (so that the Morea plugin can process all of the files in that directory in a custom manner). A few releases ago, Jekyll changed the default behavior of the --watch parameter to the jekyll serve command (which is what is invoked in morea_run_local.sh). Before, the --watch parameter would tell Jekyll to monitor all directories (even excluded ones) and regenerate the site when any of those files were touched. Currently, the default behavior for --watch is to not monitor excluded directories. As a result, you now have to kill the morea_run_local.sh process and restart to see your changes to the morea/ directory.
While the current behavior seems reasonable for Jekyll sites in general, it's not optimal for Morea sites, and I've been in touch with the Jekyll developers about the possibility of creating a parameter to customize the behavior of --watch so that the morea/ directory could be excluded but still watched. Hopefully we'll get that done in some future release.
It seem there's now a ./morea-watch.rb scripts that just solves it.
See: http://morea-framework.github.io/userguide.html#morea-watch
Related
I am working on rails app and now I am having trouble.
Early when I use to change my frontend styling and apply changes in css then they quickly show up on reload in brower.
But in present, don't know but something went wrong. Whenever I change css and save it then onload, things remain same.
After debugging, I found that app is picking styling files from precompiled assets pipeline. So for the solution, I have to recompile the assets then 2 new files are generated against wach file changed. And there will be 4 files in total against a single css file in which changes are made. So now I have to delete old ones and then have to restart the serve and refreshing the browser will show all the changing and that is weird as I have to do it all the time for every single change.
I can't figure as I am new to rails. Help....
Please clear the tmp cache first and then run the server
$ rake tmp:cache:clear && rails server
If you are developing the app, you should delete public/assets directory. Then restart the app. Don't run asssts:precompile task. Your most recent changes of assets will be up to date without restart the app.
I had the same issue and found a solution : run rake assets:clobber, it will remove the precompiled css and js. Then run yarn build --watch to build back the css and js file.
Dont run the assets:build as the same issue will revert.
This might actually be a browser issue, where the browser is caching the previous CSS and not reloading your new CSS changes.
Instead of reloading the page with CTRL+R, try reloading the page with CTRL+SHIFT+R
This will force a reload of the web page and clear the page cache, which forces all the assets to reload and fixed the problem for me.
No need to run css:clobber, assets:precompile, or anything like that! Just change the way you reload your browser :)
So I have find out the reason and it was because I have run the command of assets precompile which I shouldn't have to run as rails was doing it already for me may be due to configuration of my project or may it is its default behavior.
To solve this problem I have to delete my projects folder from my system and clone it again and things got normal again.
And now I never ever going to run assets precompile command again 😂
I have been searching all over for information on where django-cms is storing the CSS and SCSS data for my site, which I am working on localhost. When I go to edit the CSS file directly, it has no effect, so I'm wondering what needs to be done to edit those CSS files. Obviously they have been loaded somewhere. How can they be reloaded, or in general what is the best practice for editing the CSS files?
Apparently I had to do this with both the style.scss and style.css files, which seem to have the same css classes. But even after editing both files, I had to refresh the site on my localhost a few times before I could see the changes. Frustrating, but it does work to edit the files directly in the static folder.
#Lawrence DeSouza At first you should mention which plugins and style frameworks you use.
If you are using some sort of a frontend framework like Bootstrap 4 your should compile its css from scss separately. You can do it right on the dev server in a separate directory outside your project dir and cloned from the official repository. Normally you would only need to change variables in "/bootstrap-4.x.y/scss/_variables.scss" file. On the next step you would compile your *.css files with "npm run dist" command and then copy compiled files from "/bootstrap-4.x.y/dist" directory to your "/projectname/appname/static/css" directory. The process is well-documented here. After copying changed files to your "static" folder you should run "python manage.py collectstatic" and refresh the page. If it's not working after refreshing the page in a browser (normally it should work) - restart the server. I am a bit biased towards Bootstrap, but the logic should be the same in your case.
I'm currently using YUI Compressor to compress my CSS files in a project which worked fine but because of multiple files for plugins I decided to use subfolders in my CSS folder. How can I make the File Watcher also work on subfolders? I can't seem to find any documentation on this, nor have I found anyone with the same problem on the web.
I don't mind if all CSS files throughout the whole project scope gets minified, but I want to avoid defining new File Watcher every time I create a new subfolder.
PS: I see a checked "Track only root files" option in the Edit Watcher screen, but it's greyed out, so I can't turn it off. Don't know why this option is provided, since it always seems to be greyed out, no matter what settings I try.
Not sure i understand what subfolders are meant. With default scope (Project Files) all .css files in the project (root folder with all subfolders, recursively) are watched - why do you need to create a new watcher when adding a folder? Do you use some custom scopes in your watcher(s)?
Found it!
The "Track only root files" option not being optional was not the (or atleast not the whole) problem. This was bypassable by not using the default YUI Compressor file watcher template but creating a custom one.
The real problem was that my scope was set to Project files (the Root of the project) but the Arguments string being set to $FilePath$.css -o $FilePathWithoutAllExtensions$.min.css. What this means is that The watcher was searching for C:/[PROJECTPATH]/[SUBFOLDERS]/[FILENAME].css in the Project root, and then outputting it into the Root of the project (-o $FileNameWithoutExtension$.min.css).
With some fiddling with the Arguments and the Insert Macro's function i made this new Arguments string: $FileDirRelativeToProjectRoot$\$FileNameWithoutAllExtensions$.css -o $FileDirRelativeToProjectRoot$\$FileNameWithoutAllExtensions$.min.css. It now watches all [FILENAME].css files and places the minified versions in the same folder of the original.
Using the Show console: Always instead of Show console: Error option really helped me figuring out this problem since not finding a file to minify, based on the arguments, apparently is "not an error".
Hope this explanation will help to safe some frustration and hours for everyone who encounters this problem.
I struggle a while with this also due to the fact that you always have to apply settings, make some change on the SCSS File and see if it's working.
My setup is working find now for a following structure:
// Source
./scss/
- styles.scss
- _variables.scss
- subfolder/
- more-styles.scss
// Output
./css
- styles.css
- subfolder/
- more-styles.css
My File Watcher Settings look like that:
// Program:
sass
// Arguments:
./$FileDirPathFromParent(scss)$$FileName$:../css/$FileDirPathFromParent(scss)$$FileNameWithoutExtension$.css
// Output paths to refresh:
$FileNameWithoutExtension$.css:$FileNameWithoutExtension$.css.map
// Working directory:
$Projectpath$/scss/
One of the keys was to set the working directory correctly, for example $FileDir$ is just the SCSS file is in, so the relative paths are wrong.
This problem is driving me crazy... I think I've tried every conceivable combination of Sass file, ERB file, asset helper, image helper, etc. etc. Someone please give me new ideas!
Context:
Rails apps require use of asset helpers so that when the assets are precompiled, the source will be a fingerprinted asset file. I.e., if you just called img src="X.jpg", the site in production would look for X.jpg, but the file in public/assets has actually been fingerprinted as X-as;diofua;wemfiwaejfoiawefo.jpg. The only way to get to that fingerprinted file is to use an asset helper, e.g., image_url ('X.jpg').
Right now in my live site, I'm using an asset helper, but for whatever reason, it's not pointing at the fingerprinted asset. Note that the assets are found in development (but again, that's because there's no fingerprint added in development).
Code
Image titled "classic-map.png", located in app/assets/images/galleria
Image is called from a css.erb file required in the application.css file. In the css.erb file, I have the following code:
background-image: url(<%= asset_path 'galleria/classic-map.png' %>);
For reference, http://guides.rubyonrails.org/asset_pipeline.html
Note that I'm choosing to write this as a css.erb file, hence the use of asset_path vs. asset-path. Also, I initially thought that the issue might have been in interpolation, but in the page source, the url is definitely working, it's just that it's pointing at url(galleria/classic-map.png) instead of url(galleria/classic-map-apsoidufalskjf;kasj.png)
A million kudos to whoever can help!
For what it's worth, this happened to be AGAIN, and this time I could not use the hack because I desperately needed the fingerprint. So somehow, magically, I ran a rake assets:clobber and heroku run rake assets:clobber to clean all assets, and then a straight up git push to force Heroku to do the precompilation for me. That did it, and everything works.
Now, when this happens, I clobber assets locally & in production and push, forcing Heroku to precompile remotely. Similar to #user2880239's answer. I have stopped precompiling locally and checking into git.
I sat with a Sr Rails developer who still couldn't help me fix this. But the workaround we ended up using was that we just manually removed the asset fingerprint in the public folder (since the fingerpoint is what the asset helper is meant to point to).
I.e., the file galleria/classic-map-587854758918434124.png we just manually changed back to galleria/classic-map.png and it works fine.
Note that if you do this 'hack', the next time you precompile assets, Rails will create another fingerprinted asset, so you'll have duplication unless you want to keep deleting the additional fingerprinted asset each time. For me, I don't care about the duplication, I care about not thinking about this anymore.
Did you check RAILS_ENV ?
bundle exec rake assets:precompile RAILS_ENV=production
I had the same problem you did. This blog post helped me.
What I did was change a few things in my config/environments/production.rb file, namely...
config.serve_static_assets = true
config.action_dispatch.x_sendfile_header = ‘X-Accel-Redirect’
config.assets.compile = true
Note that you might not need to 'add' any of those properties since they may be pre-set to false or merely commented out.
Then I did the heroku dance:
rake assets:precompile
git add .
git commit -m "Fix static assets"
git push
git push heroku
I'm having the same issue. I even tried the helper from the rails console from heroku, and the helper works fine there!!
$ heroku run rails console
Running `rails console` attached to terminal... up, run.8071
Loading production environment (Rails 4.1.7)
irb(main):001:0> puts helper.image_path("bg.jpg")
/assets/bg-00acfb7dbe138102509d82ac2313c24d.jpg
My final "solution" was to update config.assets.compile = true in config/environments/production.rb to fallback to the non fingerprinted image.
Hope this solution could help to someone. And if you had any real solution, please make me know!
The answer to this for Heroku is in their Pipeline docs here.
By doing clobber you are basically cache-busting all your assets and forcing all clients to reload all static assets (even if they have not changed) every time you deploy your code. That is not advisable as it means every time you deploy ALL clients will experience slow loading times until all assets get cached again.
Your css file has a dependency to your image file, so you need to tell the assets pipeline about this by putting this at the top of your css:
//= depend_on_asset "galleria/classic-map.png"
This tells sprockets that if class-map.png gets a new fingerprint then the css must also get a new fingerprint. So it will only recompile the files (and dependencies that changed).
Also for others landing here, be aware that if you are using asset_path from ANYWHERE other than a view (eg in a model) you need to prepend the full context:
ActionController::Base.helpers.asset_path('your-image.png')
More info here.
I would like to move a test Drupal installation from
/opt/lampp/htdocs/corporate/internet
to
/corporate/internet
What corresponding changes changes do I have to make in .htacess, settings.php and/or other settings?
That depends on that how your sites/ directory is set up. If you just have a default directory within, they you really should be good to go.
Mostly, you don't have to make changes. This is because Drupal installations tend to be set up to use relative paths that will be valid no matter where in the system it is. You may want to do a quick search of any custom code for the string /opt/lampp/htdocs to see if someone didn't do something relatively, but any other contrib code should work fine.
As Jubal mentions, sites set up in the sites directory may need renaming if you're going to be using a different URL to access the site - if you're moving from devel.site.com to www.site.com, and you have a sites/devel.site.com directory, then you're probably going to want to copy that directory to sites/www.site.com. On the other hand, if you're using sites/default for your site, or if you're not changing the url at all, then this isn't a problem.
Do note that the .htaccess in the root directory of Drupal is very important for Drupal to work, and that doing a simple cp -R of the directory will not copy the .htaccess, so make sure you copy that. (.htaccess files in sub-directories, like sites/default/files, will be fine, it's just this one in the root.)
And finally, check your file permissions after you move the files. You'll especially want to make sure that the file permissions for the files and tmp directories are correct so that people can properly upload files. (This may not be important - but it's something to check nonetheless.)