I'm doing some research into Assetic and asset-management generally in Symfony. One thing I've noticed in the cache folder for my project (which uses Assetic) in the dev environment is the folders assetic\config, with that config folder having subfolders 0-9 and a-f.
Inside each of those subfolders are a number of PHP files with hashes for filenames and contents like this (the comment is part of the file):
// MyBundle:FolderName/twigfilename.html.twig
return array (
);
General questions: What is the point of these files? What do they do? Will they ever have more interesting content than this? (I've never found any that do.)
More specific question: Unless use_controller is set to false (ref), assets are loaded dynamically every time, so - as I understand it - you shouldn't need to clear the cache to force an update of your assets. My general rule-of-thumb is "don't bother clearing the cache for things to do with assets, just do that for Twig or PHP-file things". Given that Assetic obviously puts something in the cache, is this still a good rule-of-thumb?
Related
I am using Lando for local WordPress development.
But because it relies on Docker the performance isn't great out of the box. To solve that problem the Lando devs say we can exclude files and folders from Docker to speed things up.
So far I have excluded three folders in my .lando.yml file, like so:
name: my-blog
recipe: wordpress
config:
webroot: .
excludes:
- wp-admin
- wp-content
- wp-includes
This has made the WordPress admin and front end considerablly faster on my local machine.
But then I tried to squeeze out every last bit of performance by excluding the entire root wordpress/ directory, like so:
name: my-blog
recipe: wordpress
config:
webroot: .
excludes:
- .
When doing this I ran into issues where changes on the site (such as edits to pages etc) were not being saved.
With that in mind I have three closley related questions:
Why I can exclude those three folders mentioned above but not the root directory?
What are the potential draw backs of excluding even those three folders I mentioned above?
What are the exact WordPress files and folders that are considered safe for exlcuding this way?
Why I can exclude those three folders mentioned above but not the root directory?
It depends on what files change. Excluding a folder means only the copy inside of the container is used and you'll have to rebuild to pick up any new changes.
Think of it like this, without exclude you're creating something close to a symlink. This is where the slowness comes from, every time a file is touched in the container the filesystem has to reach outside of the container and get the file from your local filesystem.
Adding an entry to exclude is basically making a copy of the file inside of the container that does not get updated.
What are the potential draw backs of excluding even those three folders I mentioned above?
Any changes you make on your local machine in excluded folders will not be reflected in the container like you're used to happening.
What are the exact WordPress files and folders that are considered safe for excluding this way?
This depends on what you're doing honestly and how you've installed WordPress. If you've installed it via a package manager, excluding those managed folders is typically very beneficial (ie, vendor/node_modules/etc). If you do this and make changes via your package manager, you'll have to rebuild the container or ssh into the container and rerun the package manager
But it really depends on what you're going to be changing. If you're working on a plugin or a theme then you'll need to ensure the plugin or theme folders is included, and so on.
For parts of the filesystem you aren't touching or aren't concerned with seeing, it is probably safe to exclude those. They will still work within the container, you just won't have easy access to inspect anything created/altered.
I still have some problems to handle my assets in symfony. The best practices say, I should store my assets in web/.
But I dont like to store my raw sass files there, because its a public folder and I think only compiled or static files should be stored there.
Thats why I store them (js and sass) currently in app/Resources. And my assetic.read_from is app/Resources. But then there are some bundles, that are symlinked by assets:install to web/bundles/.
And now, when I want to include this bundle-assets in my twig files, I have to go there by ../../web/bundles/.. in the stylesheets block. That doesnt look very clean, so I did a symlink app/Resources/bundles->web/bundles/ and that works.
But I still think its too much fiddle and I would like to know if there is a cleaner way that better collects my assets in one place.
Don't use AsseticBundle, it was even removed in default symfony-standard 2.8. Managing frontend assets with php is workaround for someone who really don't want to use "the right tools"
I personally keep my source files in /assets/ and with Grunt JS I compile them to /web/assets/ which later is served from assets.somedomain.com through CDN
2 years ago I wrote post about managing assets with symfony, it's still valid and up to date. You might want to check it out.
http://konradpodgorski.com/blog/2014/06/23/better-way-to-work-with-assets-in-symfony-2/
I should extend post by things I learned since then but always not enough time :)
I don't see why you can't use web/ folder for your assets.
I often work with less and other file format which are afterward processed and minified.
The solution to your problem seems simple to me: Use two folder in the web/ folder.
The first folder would be your source/ folder. In which you would place all your sass files. You will add a .htaccess file to this same folder, and deny all access (you can copy from the .htaccess file in the src/ folder).
Then a second folder, lets call it assets which will hold all your compiled and minified assets.
That should do the trick... ;)
You may be interested in this topic as well. It may help to hide futher the existence of your source/ folder. ;)
If you really don't want to have your sources files in the web/ folder, then loot at this, it should help you place your sources files in your bundle.
When using ghost depending on the theme it will be grabbing the assets from the folder
ghost/content/themes/<ThemeName>/assets
Is there a general place to put assets ambiguous of the theme that you're using? The idea being to have a CSS file for a post referenced no matter which theme is currently being used.
My current work around is to have a file like so
ghost/content/general/css/file.css
And then linking it via
ln -s ghost/content/general/css/file.css ghost/content/<ThemeName>/assets/css/file.css
This is of course not optimal and I'm sure there's a better way.
Unfortunately not; Ghost is built similarly to WordPress, in that a theme is meant to be entirely self-contained. Of course there is nothing stopping you from directly referencing a hard-coded address in your themes (that may look outside the scope of its own folder), but this is not advised.
Also worth mentioning that you won't be able to use the {{asset}} helper for anything that isn't in your /assets folder.
I have recently been working an application that will soon need to be moved from one server to another. (Testing environment to live environment). The problem I am having is how can I make it so when I move folders, it will still work without need needing to change directories.
Example -
<?php include $_SERVER['DOCUMENT_ROOT'] . '/arcade/layouts/_header.php'; ?>
Here I include a layout file called '_header.php', the problem I will have when I move the test environment to the live is that we will need have the folder '/arcade' so this will be looking for a folder that doesn't exist. I could use ../ or ./ but then I couldn't be able to use $_SERVER['DOCUMENT_ROOT'].
My initial thought was to have a _config.php and in it have global variables such as
$root = "/arcade";
Then when I move from the test to the live I just have to change 1 value from "/arcade" to "" and possibly the directory to the config file.
Just looking for some insight for managing folders and files across domains
Having a configuration file is desirable anyway. Anything that is a parameter of the application (locations, access parameters etc, feature toggles, other flags etc.) should be defined there.
What is even better if you have a local configuration as well. In the configuration you can check if a local configuration exists (say config.local.php) and include it if it does at the end. This way you can have a minimal, possibly unversioned, environment specific override for settings that you need.
I have a web site built on Symfony2 which uses twig templates, LESS, and assetic.
In order to cache bust assets, I'm simply using this in my config.yml:
framework:
templating:
engines: ['twig']
assets_version: 'asset-version-here'
And then I use the asset() function to load the asset and the cache busting is handled for me.
However, the concern I have is when I load my LESS (css) file, there are references to other files, and I would like to know how these files can be cache busted as well.
Example:
.someSelector { background:url('../images/filename.png'); }
How can I make sure that the referenced file, filename.png is cache busted upon deployment?
The asset files referenced in Twig using asset() are cache busted automatically upon deployment (I use a deployment script hook that updates the assets_version in the framework's config), but those referenced in a stylesheet are not.
How can I do this?
I didn't manage to find a natural solution to this issue. In the end because I needed to move forward, I just added a certain tag in the query string, e.g. {ASSETS_VERSION}, and then I search/replace this with the revision number of the project at deployment time as part of my deployment script.
I'm not proud of this solution but it did solve my problem in the short term until I can find a more elegant solution.