I am minimizing my javascript files in my magento build to optimize page load time. I already minimized the skin/frontend/THEME/default/js files that were large, and next on my list are the varien javascript files.
My question is: Is it harmful to minimize the varien javascript files since they are technically part of Magento's core? I will obviously save backups of uncompressed files.
Thanks!
Minimizing the CSS and JS should have no side effects, that being said I have seen it screw up some of my style sheets before. Best approach is to enable each one by one in an testing environment and make sure everything looks and functions properly and look for any JS errors. Fooman speedster does the same thing that is built-in now with Magento.
If you encounter any issues disable the merging, your original files (JS/CSS) will be retained and are not modified, they are simply processed and combined into a new single file, so to answer your question it will not harm any core files by enabling such feature.
Related
My minified bundle size is 246kb. I am seeing if I can getting smaller and I read that extracting vue and jquery using mix.extract(['vue', 'jquery']); can help do this. I added this to webpack.mix.js` and now it created 2 files rather than 1. It made: 1) app.js which is 161kb and 2) vendor.js which is 180kb. What is the benefit of this if both need to be included in the page anyways?
This is mainly abut caching unchanged files. For example: while you developing app you are changing the files, adding your own code to your project and then recompile them all together. But vendors are the core libraries which you are never edit their code again. So there is no need to compile them again and download all source code in app.js file. Thus when you extract vendors which they are unchanged files then your cached content size will increase and it also decrease download time of your application because of less changed files must be downloaded again.
It helps you to optimize the file size of the files that client needed to download. Thus speed up the page loading speed even you have updated your site.
Check the documentation.
One potential downside to bundling all application-specific JavaScript with your vendor libraries is that it makes long-term caching more difficult. For example, a single update to your application code will force the browser to re-download all of your vendor libraries even if they haven't changed.
I'm beginner in Joomla So please any one help me. I'm editing on less files in both locations (media/guild/less/ and templates//less/) but changes are not reflected in front-end. Why has not reflected changes in the front-end.
It seems that your less files are not compiled to css, so no changes appear. Less can be compiled in the browser using Javascript, or via the commandline. I my opinion, there are only very few cases, in which it makes sense to compile in the browser.
To compile those files from the commandline you can have a look here
If you are new to Less/npm and all other needed stuff, you should have a look at the official docs.
As #philipp points out, Less files need to be compiled before they can be used.
Templates that use Less handle this in different ways. For example, Less files might be recompiled and saved each time you save the template settings. Deleting the Joomla cache and refreshing the front-end of the website might also trigger a recompile of the Less files.
For simple and future proof changes, it is often easier to override the CSS via a custom CSS file compared to editing the Less files directly.
When developing a module that will be reused outwith the scope of any one particular project i.e. using the community code pool, should I use the base theme to store my template, layout and skin files?
I am almost 100% certain that i should, but i see so many community modules using the default skin and theme directories that it has planted a tiny seed of doubt.
Yes, you should absolutely be using base/default for your community modules theme - in doing so you are utilising the fallback hierarchy Magento provides, allowing your theme to be portable and easy to extend by clients wishing to do so.
I'm not expecting upvotes for this answer, but would like to clarify on Tim and Drew's answers:
Unfortunately at the moment Magento only provides us with 3 levels of fall-back:
base/default
current_package/default
current_package/current_theme
Because 'current_package' is 'default' on standard Magento installations, you will often see extension developers place their files in 'default/default'. That is poor decision-making as it will mean the files will no longer be found when a non-default package is specified.
Obviously placing files in 'base/default' is also not the most optimal place, because in a sense you are removing the distinction between core and 3rd-party files. As others have mentioned, right now it is the only way of reliably adding your files while still allowing fallback to take place.
Fortunately, this will not be an issue in Magento 2, as these files will be part of modules instead, allowing pretty much infinite fallback.
Yes. Best practice is to create
app/design/frontend/base/default/template/your_extension_dir/
and
app/design/frontend/base/default/layout/your_extension_dir/
and put your files there.
CKeditor's installation instructions tell me to just unzip the whole distribution file on my webserver's production directory. But it is full of files I definitely don't want there, like source code, examples, and even server-side code in PHP. I got rid of most of these files but there is one I'm not sure about: contents.css.
I can see this file uses a lot of styles I definitely don't want to see in my site. My question is:
Is contents.css required by CKeditor, or used by default? Do I even need this file on my production site?
I suppose it depends on what you're using in CKeditor, or what you plan to use later. Personally, I'd suggest renaming the file (something like) contents.css.old and creating a new contents.css file, copy across all the styles that you think you'll need and then destruct-test your implementation of CKeditor, to assess whether you've got all the styles that you need.
Add to, or remove from, that file to get your finished version and then use that one. I'd strongly advise keeping the original version around though, for future development purposes.
To your specific questions, though:
Is contents.css required by CKeditor, or used by default?
I believe so.
Do I even need this file on my production site?
Not so far as I know, its absence will likely cause things to look a little less-pretty, though, until you apply your own styles.
As suggested, above, though, I'd rename the original and then create your own stylesheet with the same name, it's rather easier than going through all the various js files looking for, and changing as appropriate, references to contents.css.
I am looking to clean up the file that we store in source control (SVN) for the Magento projects we are working on.
Which files/folder are have no purpose being in SVN, ie the ones are not necessary for the site to function, or are only transient?
So far I have identified
var\cache
var\session
media\temp
var\locks
downloader\pearlib\download
downloader\pearlib\cache
There are some I am unsure about:
var\report
downloader\pearlib\docs
media\catalog\product\cache\
Can anyone provide a definitive list?
http://activecodeline.com/git-ignore-gitignore-file-for-magento-project answers a larger question, but could be helpful none-the-less.
There's a whole bunch of stuff in Magento that doesn't need to be in source control, as it will remain constant (as long as you follow some sane development practices.) The above link goes through all the directories that need not be tracked by source control.
I typically ignore these folders for development, but you may choose to store images if you think it's appropriate:
/var: This is always temp data or data that can be regenerated
/media: These are images and uploads, not really source code, but keep if you want
/downloader: I don't like to use Magento Connect and prefer to install things manually. You can always get Magento Connect elsewhere, so no need to keep it in the repo.
/includes/src: This is compiled source code, you can regenerate if needed. Not really that usefull since we have SSD disks and APC.
We usually have something like:
/app/etc/local.xml
/downloader
/var
/media
Media usually contains images that are configured in admin, like product/category images, logos, CMS images, merged JS/CSS and import/export data I believe.
Some extensions also have files in media that should be versioned (ex. product feed templates)
There is also an htaccess file in var and media so you have to include those.