Under the section "Cascading Style Sheets" in M. Hartl's Rails 3 tutorial he mentions copying the CSS blueprint directory into the 'public/stylesheets' folder. My stylesheets folder resides within the assets directory. Is it reasonable to copy the blueprint directory into the 'assets/stylesheets' instead of the 'public/styleshets'? If not, what might be your suggestion? If so, are there any particular pitfalls of which you might suggest I be mindful?
He clearly suggested using Rails 3.0.1, though I am running 3.2.6. I should have followed his directions to the mark, but I had an almost impossible time getting the environment up and running on my Windows machine (MySQL conflicts, etc... ) and it just so happened that this version ended up working for me so I went with it.
Don't assume I know what I'm talking about, because I'm new to RoR, but I just spent the last few hours reading up on the asset pipeline after running into problems with it. I'll share a few things I've learned that might help you conceptualize:
Anything in public/ is left just the way it is, and server as static files directly by the web server. There are two points worth considering regarding public/ assets, though:
1) They don't get the benefits of precompiling, which include:
1a) fingerprinting - Appending an md5 hash based on file contents to the filename, so that the filename changes when the file changes, forcing caches to reload. This is useful if the file might change some day (a new version of blueprint, in your case).
1b) concatenation - The precompiler can/will combine multiple CSS or JS files into one, which makes the download faster. (Exactly what files get compiled and into how many is configurable.)
1c) minification - The precompiler removes whitespace (and other clever optimizations) to shrink down the size of your CSS/JS files.
2) I'm still trying to figure this part out, but whether something is in /app/assets and goes through precompile affects whether and how helper methods work (things like asset_tag, image_tag, and javascript_include tag, which you use in your views).
Even though I'm totally unqualified, I'm seriously considering starting my own Rails Assets Best Practices page on a wiki somewhere to start organize my thoughts. I think it's sorely lacking - I've had to dredge bits of knowledge from many places, and some of what people are suggesting I find objectionable (like modifying config files to precompile add unmanifested assets).
I have copied my stylesheet files to app/assets folder and it worked normally
Hi guys : I have a "hierarchichal" styled site in compojure with a defroutes declaration like so :
(defroutes main-routes
(GET "/" [] (resp/redirect "/public/index.html")
(GET "/blog" [] (resp/redirect "/public/blogs/index.html")
(GET "/tools" [] (resp/redirect "/public/tools/index.html"))
I would like, however, for these pages to be more dynamic - that is, I would like the index.html page to be generated by scanning the contents of the /blog directory, and likewise, for the /tools route.
That is, in the end, I would like the routes to look like so :
(defroutes main-routes
(GET "/" [] (resp/redirect "/public/index.html")
(GET "/blog" [] (generate-index "/public/blog"))
(GET "/tools" [] (generate-index "/public/tools")))
Is there a simple roadmap for building dynamic paths through my site via compojure ?
More concretely ---- are there any suggestions on how to build a (generate-index) function which scans the inputted path and returns links to all files ? I assume that compojure might already have such a feature, given the recent rise of so many blogging platforms which are based on this type of idiom.
Doing most of what you said is fairly simple.
There are two things that you are going to want to look at in particular, as well as some general reading which will help you understand what's going on.
First, you are going to want to take a look at some form of HTML Templating tool. While it is possible to just build the necessary strings, things will be simpler if you use one. I've seen two different main styles for them, and which to chose depends on your tastes.
Hiccup is focused on taking Clojure data structures and transforming them into HTML
Enlive is focused on taking HTML template files and transforming them into the correct end form
For actually getting the list of files, consider using file-seq. Transform the file name into the appropriate post name and file, and then use that as data to generate the links to the pages.
The other thing you're going to want to learn more about is Compojure route templates and a little more on Ring Responses.
Compojure's route templates make it easy to pass in route parameters which you can then generate responses from. Following this is a simple example which serves a simple static html file using the html page name as the parameter.
(GET "/blog/:post" [post] (ring/file-response (str "/public/blogs/" post ".html")))
Finally, consider reading through the rest of the Compojure and Ring wikis. The Ring wiki gives some very good information on the core "how things work". The Compojure wiki provides some good examples on how to best make use of Compojure, which just focuses on providing an easy way - but far from the only way - to handle the routes and make the page generation for Ring easy.
Depending on where you want the site to go, I'd also consider taking a look at Noir, which is a framework that does a nice job at pulling together all the pieces and solving some common problems in the process.
My problem is related to the php.ini file I think, but it might be something else.
Let's say we have a site architecture where inside the root directory there is another directory named img and a file named index.php. Inside the directory img there is a file named image.jpg.
So in index.php, to refer to an image, I would use /img/image.jpg.
My question is, what should I change in php.ini to be able to write img/image.jpg instead of /img/image.jpg.
Thanks
Relative paths get resolved by the web browser, not by PHP. There is no way to override this behavior on the web server.
Nothing PHP can do. You could essentially do that with Apache rewrites but it makes much more sense to just use absolute paths. You should not try to mix absolute and relative paths because it will only cause problems for you in the future. What's wrong with adding the '/' to the front of the path?
Not only that, but it will confuse the hell out of people trying to debug your code that all of your relative paths are becoming absolute paths in Apache.
My question is, what should I change in php.ini to be able to write img/image.jpg instead of /img/image.jpg.
This is answering your question but not the answer you would like to hear. It quite simple, let's first list the ini settings:
auto_prepend_file (probably in conjunction with include_path)
And that's all. How it works:
Prepend a php script with the ini directive. inside that file, you start output buffering with your own callback function:
function callback($buffer)
{
// slash that image that you want to write without slash
return (str_replace("img/image.jpg", "/img/image.jpg", $buffer));
}
ob_start("callback");
You are now able to write img/image.jpg instead of /img/image.jpg because your output filter function does re-write it for you.
But take care that you're not trying to fix the wrong end with this. General rule of hypertext references apply, see Uniform Resource Identifier (URI): Generic Syntax
, Hypertext Transfer Protocol -- HTTP/1.1
and Hypertext Markup Language - 2.0
.
So I've got an existing real estate site. All the searches go through one php file, ie: sales_search.php?city=boston&br=4
If I create the following files:
boston-1-br.php
boston.2-br.php
boston-3-br.php
boston-4-br.php
brookline-1-br.php
brookline-2-br.php
brookline-3-br.php
brookline-4-br.php
etc…
I would then use these in place of the sales_search?city=XXX&br=NNN wherever possible and only use sales_search.php for 'advanced' searches. These new files are still dynamic as they pull content from a database.
Would this help the rankings? Hurt them? Waste of time? Thoughts? Suggestions?
I don't think they'll help, or hurt rankings. The content on the page is far more important. What is the similarity of the content between these pages? When pages are named very similar to each other it can trigger a flag to make the spider look for doorway pages. If the content is varied enough you have little to worry about.
Have you considered using a url rewriter and turning them into .htm files? There have been a lot of arguments about it, but I have personally noticed .htm files do better than .php
I am still struggling to find a good naming convention for assets like images, js and css files used in my web projects.
So, my current would be:
CSS: style-{name}.css
examples: style-main.css, style-no_flash.css, style-print.css etc.
JS:
script-{name}.js
examples: script-main.js, script-nav.js etc.
Images: {imageType}-{name}.{imageExtension}
{imageType} is any of these
icon (e. g. question mark icon for help content)
img (e. g. a header image inserted via <img /> element)
button (e. g. a graphical submit button)
bg (image is used as a background image in css)
sprite (image is used as a background image in css and contains multiple "versions")
Example-names would be: icon-help.gif, img-logo.gif, sprite-main_headlines.jpg, bg-gradient.gif etc.
So, what do you think and what is your naming convention?
I've noticed a lot of frontend developers are moving away from css and js in favor of styles and scripts because there is generally other stuff in there, such as .less, .styl, and .sass as well as, for some, .coffee. Fact is, using specific technology selections in your choice of folder organization is a bad idea even if everyone does it. I'll continue to use the standard I see from these highly respected developers:
src/html
src/images
src/styles
src/styles/fonts
src/scripts
And their destination build equivalents, which are sometimes prefixed with dest depending on what they are building:
./
images
styles
styles/fonts
scripts
This allows those that want to put all files together (rather than breaking out a src directory) to keep that and keeps things clearly associated for those that do break out.
I actually go a bit futher and add
scripts/before
scripts/after
Which get smooshed into two main-before.min.js and main-after.min.js scripts, one for the header (with essential elements of normalize and modernizr that have to run early, for example) and after for last thing in the body since that javascript can wait. These are not intended for reading, much like Google's main page.
If there are scripts and style sheets that make sense to minify and leave linked alone because of a particular cache management approach that is taken care of in the build rules.
These days, if you are not using a build process of some kind, like gulp or grunt, you likely are not reaching most of the mobile-centric performance goals you should probably be considering.
I place CSS files in a folder css, Javascript in js, images in images, ... Add subfolders as you see fit. No need for any naming convention on the level of individual files.
/Assets/
/Css
/Images
/Javascript (or Script)
/Minified
/Source
Is the best structure I've seen and the one I prefer. With folders you don't really need to prefix your CSS etc. with descriptive names.
For large sites where css might define a lot of background images, a file naming convention for those assets comes in really handy for making changes later on.
For example:
[component].[function-description].[filetype]
footer.bkg-image.png
footer.copyright-gradient.png
We have also discussed adding in the element type, but im not sure how helpful that is and could possibly be misleading for future required changes:
[component].[element]-[function-description].[filetype]
footer.div-bkg-image.png
footer.p-copyright-gradient.png
You can name it like this:
/assets/css/ - For CSS files
/assets/font/ - For Font files. (Mostly you can just go to google fonts to search for usable fonts.)
/assets/images/ - For Images files.
/assets/scripts/ or /assets/js/ - For JavaScript files.
/assets/media/ - For video and misc. files.
You can also replace "assets" with "resource" or "files" folder name and keep the name of it's subfolders. Well having an order folder structure like this isn't very important the only important is you just have to arrange your files by it's format. like creating a folder "/css/" for CSS files or "/images/" for Image files.
First, I divide into folders: css, js, img.
Within css and js, I prefix files with the project name because your site may include js and css files which are components, this makes it clear where files are specific for your site, or relating to plugins.
css/mysite.main.css css/mysite.main.js
Other files might be like
js/jquery-1.6.1.js
js/jquery.validate.js
Finally images are divided by their use.
img/btn/submit.png a button
img/lgo/mysite-logo.png a logo
img/bkg/header.gif a background
img/dcl/top-left-widget.jpg a decal element
img/con/portait-of-something.jpg a content image
It's important to keep images organized since there can be over 100 and can easily get totally mixed together and confusingly-named.
I tend to avoid anything generic, such as what smdrager suggested. "mysite.main.css" doesn't mean anything at all.
What is "mysite"?? This one I'm working on? If so then obvious really, but it already has me thinking what it might be and if it is this obvious!
What is "Main"? The word "Main" has no definition outside the coders knowledge of what is within that css file.
While ok in certain scenarios, avoid names like "top" or "left" too: "top-nav.css" or "top-main-logo.png".
You might end up wanting to use the same thing elsewhere, and putting an image in a footer or within the main page content called "top-banner.png" is very confusing!
I don't see any issue with having a good number of stylesheets to allow for a decent naming convention to portray what css is within the given file.
How many depends entirely on the size of the site and what it's function(s) are, and how many different blocks are on the site.
I don't think you need to state "CSS" or "STYLE" in the css filenames at all, as the fact it's in "css" or "styles" folder and has an extension of .css and mainly as these files are only ever called in the <head> area, I know pretty clearly what they are.
That said, I do this with library, JS and config (etc) files. eg libSomeLibrary.php, or JSSomeScript.php. As PHP and JS files are included or used in various areas within other files, and having info of what the file's main purpose is within the name is useful.
eg: Seeing the filename require('libContactFormValidation.php'); is useful. I know it's a library file (lib) and from the name what it does.
For image folders, I usually have images/content-images/ and images/style-images/. I don't think there needs to be any further separation, but again it depends on the project.
Then each image will be named accordingly to what it is, and again I don't think there's any need for defining the file is an image within the file name. Sizes can be useful, especially for when images have different sizes.
site-logo-150x150.png
site-logo-35x35.png
shop-checkout-button-40x40.png
shop-remove-item-20x20.png
etc
A good rule to follow is: if a new developer came to the files, would they sit scratching their head for hours, or would they likely understand what things do and only need a little time researching (which is unavoidable)?
As anything like this, however, one of the most important rules to follow is simply constancy!
Make sure you follow the same logic and patterns thoughout all your naming conventions!
From simple css file names, to PHP library files to database table and column names.
This is an old question, but still valid.
My current recommendation is to go with something in this lines:
assets (or assets-web or assets-www); this one is intended for static content used by the client (browser)
data; some xml files and other stuff
fonts
images
media
styles
scripts
lib (or 3rd-party); this one is intended for code you don't make or modify, the libraries as you get them
lib-modded (or 3rd-party-modified); this one is intended for code you weren't expected to modify, but had to, like applying a workaround/fix in the meantime the library provider releases it
inc (or assets-server or assets-local); this one is intended for content used server side, not to be used by the client, like libraries in languages like PHP or server scripts, like bash files
fonts
lib
lib-modded
I marked in bold the usual ones, the others are not usual content.
The reason for the main division, is in the future you can decide to server the web assets from a CDN or restrict client access to server assets, for security reasons.
Inside the lib directories i use to be descriptive about the libraries, for example
lib
jquery.com
jQuery
vX.Y.Z
github
[path]
[library/project name]
vX.Y.Z (version)
so you can replace the library with a new one, without breaking the code, also allowing future code maintainers, including yourself, to find the library and update it or get support.
Also, feel free to organize the content inside according to its usage, so images/logos and images/icons are expected directories in some projects.
As a side note, the assets name is meaningful, not only meaning we have resources in there, but meaning the resources in there must be of value for the project and not dead weight.
The BBC have tons of standards relating web development.
Their standard is fairly simple for CSS files:
http://www.bbc.co.uk/guidelines/futuremedia/technical/css.shtml
You might be able to find something useful on their main site:
http://www.bbc.co.uk/guidelines/futuremedia/