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.
Related
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.
Our institute has Plone 5.0 and 4.3 running and are migrating dozens of older plone sites into them.
We have created a Diazo theme and it is hosted to provide our theme out to all plone sites. There are specific plone pages like the Login that must be changed. There are two ways we see to do this:
Portal View Customizations. Problem is we can't host this template centrally and can't change it one place to change it everywhere. This will bring maintenance issues.
Diazo. We could put all the html in the index.html and then drop code we do not need through the rules.xml. However this feels super hacky and inelegant. The index file will grow and grow in size.
What is the best approach to something like this?
My idea: (Please tell me if this good or bad)
In Diazo, the rules.xml would load a subset rules file called login-rules.xml. In the login-rules.xml, I'd put a replace rule. The replace rule would have within it all the login HTML.
You've really got two kinds of problems here.
One is deciding where to intervene for your login pages. The other is how to manage deployment of custom code.
If the changes you need are strictly ones of presentation, Diazo is a reasonable place to handle it. Remember that you may use different theme documents, with your rule set making an early decision of which theme (html) file it uses under what circumstances.
If the changes you need are beyond simple presentation and require custom logic, or if the presentation changes start to require complex custom XSLT, make the changes via view customization. But do not do that with the Portal View Customization tool. Customizations that are needed on multiple sites should go into Python packages maintained in a source-control repository like git. That goes for Diazo rules and theme files as well as templates.
You may create the skeletons for these packages with ZopeSkel or mr.bob. Use the JBOT method within these packages to customize individual template files.
Managing deployment is much easier when you're using file-system packages from a repository. You may use mr.developer within your buildout to automatically check out the current version (or a particular tag or branch) of a package when you run buildout. Then, when you need to push changes to multiple servers, you run buildout on each one and restart the ZEO clients. That may be automated with tools like Ansible. See Plone's Ansible Playbook for examples.
I've used several bits of Plone-specific jargon in the above. All of these are well-documented at http://docs.plone.org.
In my webdesign process i use jade, sass, coffe etc. to generate static files via a GruntJS watch task into a dev folder. And most of the times after the build process is done, a cms comes along and want some templates to work. Thats usually html files with some php/ruby/python tags in it. Let´s say it´s a Wordpress Theme.
The Problem is:
i have to modify my generated files in the dev folder directly
when im modifing my source jade, html, coffee - files, the dev folder would be overwritten
if i clone the static files and move them into the theme folder, i have to apply manually every change i made to the src/dev folder to the cloned theme template files.
that´s very odd. So i´am in need of a grunt task that maybe...
generate the templates for me out of the static files (via a json mapping file)
generate the templates directly from the src files via special attributes, comments or something similar
There´s just one thread i found where the user tries to accomplish the same with jsdom.
Can someone help me to find a existing tool that accomplish such a task or do i have to build it on my own?
Thanks, Robert
Check out grunt-usemin
Replaces references to non-optimized scripts or stylesheets into a set of HTML files (or any templates/views)
I'm helping a colleague configure a new box for an existing Drupal install with multiple sites. It's functioning, but I've noticed that all assets are being referenced as /sites/<site-name>/files/image.png. I don't know from Drupal, but it strikes me that Drupal should be abstracting the logical site from the code so that site-specific assets could be referenced as /files/image.png and Drupal would figure out -- perhaps based on HTTP_HOST -- which site is meant.
In this case, we need separate snapshots of the same site (dev and staging) so we'd like to be able to store the paths without specifically referencing one site or the other. We can do some rewriting to manage this, but I'm wondering whether there's something that we simply don't know.
Does Drupal do this natively in some way? If not, what are others doing to manage this kind of abstraction? Surely we're not the first to encounter this and think there must be a better way.
Thanks.
That would be an interesting module. The Files directory can be in the following locations:
sites/<site name>/files (standard for multi sites, public)
or
sites/default/files (standard installation for single sites, public)
That is, if you want to use the public files method.
Read here if you want to learn about the private files method (very similar to your thought): http://drupal.org/documentation/modules/file
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.)