How to properly install/use LESS in CodeIgniter - php

My original problem was linking multiple stylesheet frameworks. My primary option was Materialize and for reasons, i'd like to integrate Bootstrap on some buttons and other components. After hours of desperate research, i found myself staring at css pre-processors, e.g. LESS and SASS. I found out that you can do dynamic css using these badasses.
Investing a couple more hours deciding which to use, I ended up failing to install both.
So far I managed to download bootstrap sass and integrated it inside my project and compiled it using grunt (follow this instruction). I don't know how to use it and where to start.
I found some cool references here but it was not enough to get me going.
.bootstrap {
#import "/bootstrap.less"
}
I have so my follow up questions to the post:
should I link the less file on my index.php?
can I use any editor and compile the less with any less compiler?
should i link the compiled less or the created css?
do I even need to use LESS for this?
Note: I'm a total newbie with LESS and SASS. Any information is a ++.

I personally prefer Sass and I use it a lot even for small CSS stylesheets!
Here you are my answer:
Absolutely not! A less file is not intended for browser parsing. It is intended only for development purpose, that is to produce one or more .css file.
Feel free to use any editor you prefer and compile with any compiler you prefer. For example, I use Scout-App for Sass.
You must link only .css produced files.
It depends on your project and/or your needs. LESS and Sass are very similar.
Other tips for you:
Install on your CodeIgniter app an asset helper, and in asset folder place your css and less files. See the directory structure below:
application
system
user_guide
assets
--css
--less
--js
--img
ecc...
Put your less file separated from your css file. Link css file with the asset helper and you will have autoupdatable style!
If you use Git, remember to ignore css folder and track less or sass folder.
I hope you can find these tips helpful!
UPDATE: It's a shame that no one answer to this question in time!

Related

What is purpose of these files in CodeIgniter?

I have been working with CodeIgniter since 2 years. But I have no idea about following highlighted files.
What are them?
What happens if I remove them?
.editorconfig -> here's the website. It's a configuration file to keep settings / code styles for certain IDE's.
.gitignore is a file used by git version control system which tell it which files should be IGNORED by git.
composer.json is a file used by Composer dependency manager (for PHP libraries), and that file lists library dependencies, versions, required php extensions and their versions which are needed for the code to run properly.
contributing.md isn't a special file, it's just a markdown-formatted file that contains instructions left there by the author. You can see that StackOverflow, Github and many other popular programming-related websites use markdown and display it as nicely formatted HTML after parsing.
You should really know what GIT and Composer are, so I suggest checking out the links I posted and implementing a bit of google-fu to get up to speed with current tech!
.editorconfig: This is a file to set coding style in IDE
.gitignore: This file is for git. You can tell GIT,that certain files are not allowed to be loaded into git.
composer.json: This file is for the libraries in php. It controls the loading and includes all dependencies.
contributing.md: Contains guidelines for contribution, for example, in an open-source project this file plays an important role to provide guidelines for coding standards.
I suggest you keep those files, especially the first three files. DON'T delete them.

How/Where does SuiteCRM compile the scss files in a theme?

I'm currently working on setting up a custom admin page for a specific task I need to do and it requires some custom styling in the theme. I went to the themes/SuiteP/css folder and found admin.scss. After making a change, I had assumed that Suite would dynamically compile the asset since I am developer mode; however, that did not happen.
I decided to search the code for any place I could find that would deal with compiling those files to *.css, but found no such place.
My question involves inquiring as to where that compilation takes place and/or how it takes place. Right now it appears as if I have to manually compile those assets, which seems pointless because it is just an extra step I have to manually take, rendering using SCSS less useful in comparison with CSS.
Right now, my solution will probably have to be adding a CSS file that has nothing to do with whatever pipeline exists, but if I can leverage existing functionality, that would great.
Due to legacy issues with the SugarCRM framework, SuiteCRM loads style.css for current theme. The sass work for SuiteCRM is in a transitioning period. It is currently a manual process, but we hope to make it automated in the future.
We are using Sass as a way to allow developers to customise the SuiteP theme. I have a github project which provides a UI to generate the variables.scss for you. I am hoping that it will be accepted in a future release.
So in regards to your workflow you only need to care about the style.css.
If you want to contribute back to the SuiteCRM project, then you will need to use the sass files in themes/SuiteP/css/.
However, if this is just for your instance of SuiteCRM, then you will want to create a style.css in the custom/themes/SuiteP/css/style.css. How you change that is up to you.
I would recommend that you use Sass to generate the style.css.
You can achieve this by copying the style.scss file custom/themes/SuiteP/css and then add the following to the file
#import ../../../../themes/SuiteP/css/style.scss
Note: I may have the path slightly wrong
or use the command line tools to include the themes/SuiteP/css/ directory
See for details:
SASS: Import a file from a different directory?
SuiteCRM should pick up the rest of the work. There is a change in SuiteCRM 7.9 that deprecates the $sugarcrm_version in favour of $suitecrm_version. This will effect theme themedef.php.
See for details
https://github.com/salesagility/SuiteCRM/pull/3233/files
I hope this answers your question.

Methods to minify js/css files into assets with some generated key

I am have been building web applications for several years, exploring and looking for ways to improve the web app performance. I would like to ask if there is any method to minify css/js when we launch the web application automatically? I do not use any php frameworks, rather i built my own.
I was exploring one web application and i saw they have this
<link href="/assets/application-76c372b1409e29d226c9566022d5546f.css" media="screen" rel="stylesheet" type="text/css" />
<script src="/assets/application-cb571d9ff5185e712000e3378494e4ee.js" type="text/javascript"></script>
I seen similar sites that has js and css files stored in /assets/ etc with a name starting with application- too. I would like to know if anyone of you know what mechanism they are using? I am sure they compressed their files the same way.
Any idea what framework/programming langugage they are using?
advice appreciated. thanks
Often this functionality is built into the web framework that you are using, or an external series of programs like SASS, Compass, Uglify, and Grunt do the work. There are MANY ways to do this, but I'm going to explain the principle and just one way of doing it.
Generally, the principle is that during your deployment process, you concatenate all of the files together, take a hash (like an MD5 sum) of the content, and create a file name based on that hash.
So for example, if you had:
source/assets/reset.css
source/assets/main.css
source/assets/fonts.css
You could clear out the output assets directory, which is separate from the source assets directory so you don't overwrite anything, then concatenate these 3 files together, take the MD5 hash, and then create a file named application-$hashvalue.css, and write the contents to it.
Concatenating is helpful, but you could also run it through a minifier such as CSSMin, JSMin, Google's Closure Compiler, and many others.
Now that's all if you want to do it by yourself, by hand. You're of course not the first person to solve this problem, and there are a variety of tools to do this for you.
An general example set of tools to do this for you:
Grunt, as a task runner. Sort of a supervisor of everything else.
Uglify, a minifier for JS
SASS + Compass to manage and minify your CSS
grunt-contrib-uglify: a plugin to connect Grunt to Uglify
grunt-contrib-compass: a plugin to connect Grunt to Compass
So then you just run your grunt file and it will compile everything out for you. You could do this during deployments or have a directory watcher running locally.
PHP-specific asset management:
https://github.com/kriswallsmith/assetic
Unfortunately that's the only one I know of, as I don't use PHP much anymore.

What's the point of Yii's AssetManager?

I can't find much information about Yii's AssetManager for the management of JS and CSS files. My question here is what is the point of using the AssetManager? I'm not sure what value it adds to my development process, in fact, it seems like it complicates my code... every time I change my scripts or css code, I have to go in and delete my assets folder to make sure I have the latest versions.
Seems it is much simpler to just put all Javascript files under /webroot/js/ and just use the tags to load the files instead of going through the trouble of AssetManager. Plus, Yii's registerCoreScript function always places script tags inside the header tag, instead of placing them at the bottom of the code, near the closing body tag, as recommended by YSlow.
I think there must be a gap in my understanding of Yii's AssetManager. Anybody have any ideas why using the AssetManager is better than hard-coding the script tags inside the PHP code? I'm a bit confused...
Thanks!
I'm sure someone can answer this better than myself, but basically it's so that your source JS and CSS files can remain in your Protected folder.
This is a little more secure for one thing, but the main benefit to me is that you can compress and minify and otherwise process your assets with the asset publishing system, and it makes it easier to host your JS and CSS on a CDN since it's separate from your codebase.
Also, here's an official response from qiang (the guy who wrote Yii) about this.
The main benefit of Yii's asset manager is that it allows you to structure your components in a self-contained manner.
A tale of a widget
Consider a component that is a UI widget. Let's assume the distribution includes a couple of assets along with the component implementation, for example these files:
SuperWidget.php
superwidget.css
superwidget.js
image_for_css.png
Consider how you would incorporate this widget into your application if the asset manager did not exist. Typical steps might include:
Copy SuperWidget.php somewhere inside the protected/ directory
Copy superwidget.js to your js/ directory
Copy superwidget.css to your css/ directory
Copy image_for_css.png to your images/ directory or perhaps also inside css/ to help reduce the relative path dependencies
Then at runtime SuperWidget would emit appropriate tags to include the CSS and JavaScript; to do this, it would need to know where exactly you have placed these assets. In other words: some choices regarding the installation can be made arbitrarily, but then they are set in stone unless you go and edit the source.
Is the widget reusable?
If this widget were highly customized and meant to be an inseparable part of your application then this approach would work fine and there wouldn't be much need to have an asset manager. But what if it's a broadly useful component that you want to distribute?
Problems start arising.
First of all the deployment scheme we have examined requires users of the widget to copy different files into different directories, complicating the installation procedure and increasing the chance of error.
But the greater issue is that your deployment scheme could conflict with that of any other component developed independently of yours. What if someone else decided to have a superwidget.js file too?
If the installation instructions for these two components conflict then obviously one of them cannot be installed as intended, and then you resort to changing some details and hacking the source code of the component to accommodate these changes. If you later upgrade to a newer version of that component you will be forced to carefully account for your customizations, making a "copy/overwrite" upgrade impossible.
All of this is really not pretty, and while it can be unlikely to happen in practice it certainly doesn't feel right.
Asset manager, make it so
Here's where the asset manager comes in. Let's assume you decide to structure your component like this:
superwidget/
SuperWidget.php
assets/
css/
superwidget.css
js/
superwidget.js
images/
image_for_css.png
You can directly copy this somewhere inside your protected/ directory no matter what other components you have installed; the worst thing that could happen here is that you'd have to rename superwidget/ to something else if there was a conflict.
Using the asset manager, SuperWidget.php publishes the whole superwidget/assets/ directory, with the copy ending up at e.g. assets/1337c0de/ where assets/ is your application's base asset path and 1337c0de/ is a random hash created by Yii and guaranteed to not conflict with any other published asset.
This means that the assets for SuperWidget cannot possibly conflict with those of any other component, making SuperWidget truly reusable. And since the directory structure inside 1337c0de/ will be the same as in your distribution, CSS can refer to images using the relative path ../images/ without needing to refer to the value of the random hash (which is only know after publishing).
What the asset manager is not
It's not a way to increase security. Your component source would be somewhere inside protected/ anyway (so no improvement there), and the assets need to be web-accessible no matter where they end up being copied (no security for them no matter what).
It's not a catch-all solution for processing your assets (e.g. minifying CSS). While it is possible to install a custom asset manager that does this, don't forget that assets included with reusable components will a small minority among all of your "base application" assets; if you want minification across the board, you 'll have to also process everything else and the asset manager will not help you there.
TL;DR
The asset manager allows you make components that are easily distributable and can be included in applications without the fear of creating conflicts with other components.
Another perk that I like about the asset manager, is that it allows you to update your asset files without having to tell your users to clear their cache.
http://www.yiiframework.com/wiki/311/assetmanager-clearing-browser-s-cache-on-site-update/

Best practices for php project organization using GIT?

I'm working on releasing a PHP framework I have been using for a few years
on github. Been trying to read up on the most correct way a project
should be structured, what extra files such as readme's etc should be
added. Been coming up with blanks on google. Can anyone point me to a
project that's a good example or any good write ups.
Some PHP projects hosted on Git(hub) include:
CakePHP
Gallery3
Garden
PHPUnit
Kohana
I'd just make sure that no temporary files, etc. get in the repository by creating a .gitignore file, and add some readme's etc. to the root of the repository.
Any configuration files should also be ignored, and sample configuration files should be created in the repository.
I'd recommend writing the readme file in a format that Github supports, like Markdown. It'll make your repository front page look better.
You might want to follow some kind of class naming guideline to make things like autoloading easier to implement. For example, the class MyFramework_Controller should be located at directory /lib/MyFramework/Controller.php.
You should just create some kind of basic layout for now - it'll be easier to give suggestions when we can see what you have right now.

Categories