So I understand that a similar question has been asked somewhat before : Structure a stylesheet to manage skins or themes Although I think due to kapsula not being able to articulate (him/her)self properly it was deemed unclear.
I am working on a large project with mulitple CSS/LESS files. We have broken up a lot of the monolithic CSS files into individual ones for CSS specific to certain pages as well as common CSS files for common elements on each page (menus, image placeholders, etc..)
We would like to incorporate multiple themes for the project so we decided upon the following structure:
In the base directory we have all the CSS/LESS specific to all the pages in project, except the colours which we set in the theme directories which are situated within the base directory.
So it looks something to the effect of this:
-CSS
- ORANGE [directory]
-> classic.less
-> controls.less
-> classic.less
-> controls.less
Inside the classic.less file in the ORANGE directory we simply insert the directive #import "../classic.less" and upon saving the file our CSS is generated with all our lovely colour themeing as stipulated in the ORANGE->classic.less file.
So while this process has saved a little bit of work in terms of management of the files, every time I make a change in base directory (maybe i added a new element type to the front end) I have to go into each LESS file that inherits from it and save it again in order for the new CSS to be generated.
Is there a more efficient way of doing this? Or am I looking at doing themeing in an incorrect manner. Should I illustrate what I am trying to do a little bit more?
There is a more flexible way, but you'll need WinLess (maybe it's doable with something else, I just found this to serve my needs) which requires Windows. There should be something similar for other OS'es if you search.
What I've done is, in the CSS or Stylesheet folder of my project, I've created another one named LessBase. Here I keep the core stylesheets. Example:
-Stylesheets
-LessBase
->jquery-ui.less
->forms.less
->buttons.less
->grids.less
->widgets.less
->etc
Then, in the Stylesheets folder, you'll need additional folders with your individual themes. Building on the previous example:
-Stylesheets
-LessBase
->jquery-ui.less
->forms.less
->buttons.less
->grids.less
->widgets.less
->...
->all.less
-Orange
->color-theme.less
->main.css
-Black
->color-theme.less
->main.css
Please note the all.less file. This one is used to import all the files within the LessBase:
#import "buttons.less";
#import "forms.less";
etc
The color-theme.less will basically hold all of your colors. Inside LessBase, all of your .less files will have variables which will be defined in each of the color-theme.less file residing in the theme folder.
Your color-theme.less file might look like this:
#main_color: #edf123;
#secondary_color: #daa123;
#border_color: #e7e7e7;
.
.
.
#import "../LessBase/all.less"
The import of all.less has to be at the end, in order to have the variables defined.
Then, inside WinLess you will make the color-theme.less compile into the main.css placed in the corresponding theme folder.
Here is a screenshot with an example (I blurred out the sctructure. Also, default_1, default_2 are the theme names, replace them with orange, black or whatever theme name you have):
Related
I have two questions.
Question 1:
Is there any way I can download the website based on the following structure using winhttrack?
All of the html files go into site_name/
All of the images go into site_name/images
All of the css files go into site_name/css
All of the js files go into site_name/js
I tried to use winhttracks different build structures and the one I've found is pretty close to what I need.
Html in site_name/ .images/other in site_name/xxx
This structure gives me this result
All of the html files go into site_name/ Good
All of the images go into site_name/images Not Good
All of the css files go into site_name/css Good
All of the js files go into site_name/js Good
Just the image section. it saves images based on their extensions also in different folders like
All JPGs go to site_name/jpg
and so on.
So I've searched and found that I'll have to write user defined structure for this. But Can't find any good guide with some examples explaining it.
Can anybody help me out of this?
Question 2:
Winhttrack saves same file with different queries. So style.css saves as
style.cssf972
style.css86ff
How can I avoid this?
I work on a very large enterprise web application - and I created a prototype HTML page that is very simple - it is just a list of CSS and JS includes with very little markup. However, it contains a total of 57 CSS includes and 271 javascript includes (crazy right??)
In production these CSS/JS files will be minified and combined in various ways, but for dev purposes I am not going to bother.
The HTML is being served by a simple apache HTTP server and I am hitting it with a URL like this: http://localhost/demo.html and I share this link to others but you must be behind the firewall to access it.
I would like to package up this one HTML file with all referenced JS and CSS files into a ZIP file and share this with others so that all one would need to do is unzip and directly open the HTML file.
I have 2 problems:
The CSS files reference images using URLs like this url(/path/to/image.png) which are not relative, so if you unzip and view the HTML these links will be broken
There are literally thousands of other JS/CSS files/images that are also in these same folders that the demo doesn't use, so just zipping up the entire folder will result in a very bloated zip file
Anyway -
I create these types of demos on a regular basis, is there some easy way to create a ZIP that will:
Have updated CSS files that use relative URLs instead
Only include the JS/CSS that this html references, plus only those images which the specific CSS files reference as well
If I could do this without a bunch of manual work, if it could be automatic somehow, that would be so awesome!
As an example, one CSS file might have the following path and file name.
/ui/demoapp/css/theme.css
In this CSS file you'll find many image references like this one:
url(/ui/common/img/background.png)
I believe for this to work the relative image path should look like this:
url(../../common/img/background.png)
I am going to answer my own question because I have solved the problem for my own purposes. There are 2 options that I have found useful:
Modern browsers have a "Save Page As..." option under the File menu, or in Chrome on the one menu. This, however does not always work properly when the page is generated by javascript
I created my own custom application that can parse out all of the CSS/Javascript resources and transform the CSS references to relative URLs; however, this is not really a good answer for others.
If anyone else is aware of a commonly available utility or something like that which is better than using the browser built in "Save page as..." option - feel free to post another answer.
I've just started tidying up the server for a particular site and am running into some trouble when moving files.
I originally had style.css in my main folder, and another folder called images, so paths in the .css went images/myimage.png
Now I have moved style.css into another folder called css.
So the image links in the CSS no longer work, as it's looking for the folder images from it's own CSS folder.
I changed the file path to /images/myimage.png as I thought this would make it climb up a level and then look for the images folder, but this doesn't seem to work.
I'm interested to see what solutions people have and also any suggestions on how people organise their folders for a particular site.
Thanks!
Do this ../images/myimage.png
This should work, for each level you want to go up, add ../
Primary resources I structure in a way that will give some sort of mnemonic to the client process. E.g. if I have a bunch of resources representing employees, I'd put each at /employees/alice, /employees/bob, etc. If I have a resource representing all employees (a list etc.) I'd put it at /employees/, but if I didn't I'd still use that structure.
If this hierarchy is relatively simple, I'll follow it in terms of where I place the files.
If modelling something that is in itself hierarchical, I'd follow that hierarchy in the URI mapping. E.g. /ireland/leinster/coDublin/dublin. In this case I'd rather have the handler somewhere that doesn't have a direct correspondence to the path, like in wwwroot\placesHandler, as following it a bit, but not fully is less clear than obviously not following it.
For secondary resources like images, css, etc that are just part of rendering an entity rather than of primary interest to the client process, (most common on browser-focused human-readable sites). I normally just have an /s/ an /i/ and a /js/ and go with the fact that by default pretty much all webservers will mirror the directory structure of your files in the path-structure of the site. Within those I'll group /i/ and perhaps /js/ according to purpose.
And as I said in the comments, /images/myimage.png will mean http://whateverTheSiteDomainIs/images/myimage.png, to "climb up one" you want ../images/myimage.png.
I was wondering how other people are organising their assets for individual posts when using Jekyll. For example, if a post has an image, do you just dump it in a shared images folder? I don't really like the idea of doing this - it means that an image is completely separated from a post, when I think they should be paired.
I wrote a plugin to let me organise assets in subdirectories easily:
https://github.com/samrayner/jekyll-asset-path-plugin
{% asset_path my-image.png %}
in post 2013-01-01-post-title would output:
/assets/posts/post-title/my-image.png
in page my-first-page would output:
/assets/my-first-page/my-image.png
I prefer to think of images as stand alone assets that are included in zero or more pages. Most of the time, my images show up in a single page. There are times when I want to have them in multiple pages and in other cases I don't link an image at all. If your workflow is to put each image in a directory with a post, finding them starts to require a significant amount of searching and you have to come up with something different for images that don't belong to a specific post.
The approach I use is on the opposite side of the spectrum. I have a single image directory (served from "/images") and 100% of my images are housed there. Benefits of this are:
When I'm adding an image to a post it's easy to know what path to use. It's always:
/images/{image-name}
For example: http://alanwsmith.com/i/aws-20111017--0906-02. This makes it possible to write a plug-in so all you have to enter is the image name and the rest of the known path is filled out automatically.
With an application like Photo Mechanic, it's incredibly easy to browse the single directory locally and see every image. If I want to include an image on another page, this drastically reduces the time to find it.
There isn't a separate location/process if I want to send an image to someone without actually including it in a page (i.e. send them a direct link to the image file). I just throw the image in the standard directory and send the direct link.
If you want to get a little more advanced, keeping all your images in a single directory makes some nice tweaks possible as well. For example, even though the URLs for my images start with "/images", the images are actually stored in a directory outside of the ones jekyll uses. In my case, the top of my source tree looks like this:
./html
./source-files
./image-files
All of my images are stored in the "./image-files" directory. In my apache config, I've setup an alias so that the URL "/images" points to the "./image-files" directory. For example:
Alias /images /webroot/image-files
When I run jekyll, it process everything in "./source-files" and drops it in "./html". Because all of the images are outside those two directories, jekyll never sees/touches them. As your image library grows this will help speed things up and will prevent a tremendous amount of unnecessary file copying.
Another tweak I like in Apache is turning on:
Options +MultiViews
This lets you call your images without having to use the file extension (e.g. no '.jpg', '.png', etc...). You can see that in the example link I provided above. It doesn't really matter for performance. I just like the way it looks and it saves me from having to type the extension every time I'm calling an image.
MultiViews also makes it possible to replace an image of one format with another without having to recode anything else. For example, if you remove "some-image.gif" and replace it with "some-image.png", you wouldn't have to touch any HTML. It would still be served form "/images/some-image". Needing to make changes like that is probably exceedingly rare. I just think it's an interesting thing to be able to do.
Finally, you can make a single decision about allowing or disallowing your image directory to be browsed. Personally, I only want my images to show up where I place them. So, I've set the .htaccess file in my images directory to:
Options -Indexes
If you are going to be working on a site with many thousands or tens of thousands of pages and images, this might not scale. For a normal sized, personal site, I find that this approach makes maintaining images easier.
I have now managed to develop a Jekyll plugin that helps keep posts assets alongside the Markdown file:
https://nhoizey.github.io/jekyll-postfiles/
Just like you, I really hate having all images in one single shared folder.
Most, if not all, of my images are useful in one single post, and keeping them alongside the Markdown file is really better for posts management:
I can drop a new post as one single sub-folder of /_posts/ in one step, without having to put the Markdown at one place and the image(s) at another
When I want to edit the image(s) of an existing post, I don't have to find the right image in a huge /assets/ folder, it is located just near the Markdown file
In my Markdown, I can use the image file name directly, without any path
If I want to use any Markdown editor with live preview, it works, no need for a specific assets folder configuration
I tried to have this for my blog (example post here).
For responsive images, I used the Jekyll Picture Tag plugin, but I had to fork it, because the Pull Request to deal with such paths was not accepted.
Now that Jekyll 3 is there, I wish it could let us use images both in a post folder AND in the /assets/ one, looking for an image marked with  in both, in that order.
For JavaScript and CSS, you may want to consider an asset pipeline. You can get a good performance improvement through bundling and compression. I also use CoffeeScript and Sass, so I needed a preprocessor to convert my assets. I use Jekyll Asset Pipeline to manage this whole process automatically when I run the jekyll command.
For images/video, I recommend you develop a convention for naming folders in your project. I generally have an "assets" folder then subfolders with the date of each post that holds the images related to those posts. If you have multiple posts per day, you might consider including the name of the post.
This answer:
Does not use plugins (works with GitHub Pages)
Allows you to keep images directly next to their relevant posts
Allows you to edit using Typora locally and see the images WYSIWYG
Just name your folders like _posts/2020-10-10-My-Title/ and include files like index.md and hero.svg or other images.
Then set your permalink: key in _config.yaml to :path.
Caveats:
Your folder names must be sluggified
Your images must all be SVG
So I'm trying to set up an environment where I can generate a new project and minimize the customization/complexity involved in setting up that new project. I'm using Structurer Pro (from nettuts+) to build the fileset, and this is an awesome thing. I've got github for MAC set up, allowing me to grab the latest Foundation framework files and put them in to the current project.
Now, I'm trying to incorporate LESS into the process also. However, Foundation's css files aren't currently set up with LESS, which means I have 2 options...(1) take a current version and LESS-ize them, then use those customized files to create new projects. (2) don't use LESS...
The other problem I have is, there seem to be quite a few compilers for LESS (simpLESS, CodeKit, LESS, compass), but none of them combine css files! So if I set up 10 LESS files (e.g. IE.less, mobile.less, grid.less, typography.less etc), and have the variables in them, I really don't want 10 css files as the output. I really want 1 compiled css file as the output. I know I can do this manually, or even through Clean css or any of the 30 other sites out there...
But is there one 'thing' out there that will let me use the latest files to create a project framework, customize it by applying a color swatch set to a series of variables (LESS), then compile & combine the resulting CSS for actual implementation?
Foundation ended up moving to SCSS in version 3, so this became kind of a moot point...
Trying to answer some of your questions:
Rename Foundation's .css files to .less and put in your /less/ directory.
Any .css file is a valid .less file (not vice versa though)
You don't have to convert this CSS to LESS, do so only for things you're going to be modifying, and save some time ;)
In your master.less file import these files with #import 'foundation-file';
re: how to combine css/less files :)
Compile only the master.less and include it in your HTML
master.less is your assumed MAIN stylesheet which may actually contain only #import statements, for me it's easier to manage everything this way (and where the combination happens). it will compile to master.css which you then use.
I'm not sure what css foundation includes, if it's a reset.css or something similar I would just leave it and not less-ize it. You would have two css files: one reset.css and one styles.css (the latter of which would be compiled from less files).
You could then add your own setup including a style.less which #imports the various components, if you make this generic enough you can reuse it throughout various projects.
The lessc compiler does handle the #imports of various files and combines them into one file: I have styles.less which #imports base.less components.less etc. I just compile the styles.less to styles.css and it handles the rest:
lessc styles.less styles.css
See: https://gist.github.com/1480684