I am doing a project in Symfony2 and I have a problem with assetics. I use to compress assetics yuicompressor but the command:
app/console assetic:dump --force --watch
does not work i get always this error after some time:
Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 32 bytes) in /Applications/MAMP/htdocs/optinet/vendor/twig/lib/Twig/Node.php on line 225
I've tried all the ways but not working always get the error.
thanks.
In order to work around assetic in general with assetic:dump --watch like commands dig into Guard or Grunt ! I moved there because of similar performance problems and lacking configuration options in assetic.
The watch command has the downside of only being able to run with debug option.
Grunt/Guard aka. task watchers are able to automatically re-dump assets, run unit-tests and livereload your browser on changes to controllers or assets.
watch a quick Guard introduction on nettuts to get an idea about how this works
They even provide nice integration for GROWL (OSX / Windows) and libnotify ( *nix ) notifications for completed/failed tasks.
Use one of these in combination with CoffeeScript,SASS,LESS, ... source-maps for maximum frontend productivy.
If you use Chrome and Tincr with assets:install web --symlink you can even edit/debug your css and js directly in DevTools and save them back into your current bundle structure without leaving the browser.
Firefox has recently added source-map support in Aurora.
Assetic currently lacks the source-map options needed for various pre-processors but i'm working on that already ;-)
Related
I'm currently having a mental breakdown, hitting my head against different walls.
I'm trying to get my app online to prod, and have been trying for weeks now.
I've had this error a lot : Symfony - twig - Autoloader expected class
Now, it's evolved, and I have this :
Sometime, after clearing cache, running composer install / update a dozen time, this error goes away and..... I get the old error again!
Please help if you've ever seen anything like this
How are you making deployment on prod environment?
Maybe there are some files doubled so loader doesn't recognize them correctly?
Some deployment methods dont remove files deleted at project (php storm deploy).
Last times i had error with Twig_Environment. It was after i upgraded my project's Symfony version from 3.3 to 3.4.
To Sf 3.3 all services defined at services.yml at enabled bundles was PUBLIC.
Since 3.4 they are all PRIVATE by default.
What i did was to add some .yml code at every services.yml file i had:
_defaults:
public: true
Without this code Twig_Environment could not see some Twig Extensions and other classes.
Also I have read your last post. So You don't have access to console, yup?
Maybe try to have second instance of Your project (locally) where everything is set up to prod env?
Then try to:
composer dump-autoload -o
And other preparings for prod:
php bin/console a:install --symlink
php bin/console a:dump --env=prod
php bin/console c:c --env=prod
After this You should upload vendor/autoload.php, generated assets, etc. at production server. And this should happen every site update.
It's really bad having Sf project withoud ssh access.
I am following the installation guidelines as described on mean.js.org Everything seemed to install fine. I have all prereqs installed. I ran npm install after cloning the github repo and then tried to run grunt and I didnt get any errors however It seems to just be stalling on the command line. Last message on the command line is the "debugger is running on port 5858" and then it just sits there.
After some time the message [nodemon] watching 51,839 files - this might cause high cpu usage. To reduce use "--watch" comes up. I am on windows 10 and have all the latest versions of node,npm,grunt and mean.js. I am running the command line as admin.
Mean.js should be running on localhost:3000 but it is not.
This is intended.
There is an application invoked by the grunt command and running in background, watching your files for changes. In default configuration: nodemon and grunt-watch.
This will execute specific tasks based on the files you edited, such as linting JS files or compiling LESS files.
The cmd will probably show something when you edit files in the projects directory.
Situation:
Production mode
Change a file
One of the pages on the site returns the following 500 internal error.
Run composer update, and the error goes away.
Change a file and the problem returns.
The code calling the twig_upper_filter is buried deep inside the now embedded in symfony bootstrap templates.
What does composer update do that might fix this? It is repeatable (on one server only).
UndefinedFunctionException: "Attempted to call function
"twig_upper_filter" from the global namespace." at
Symfony 2.6.
Because at the end of composer update it does a cache clear, everytime you change something somewhere you need to clear the cache for the change to be visible in the production enviroment.
This is automatic on the development enviroment.
You need to run this from console:
cd /your/symfony/app
php ./app/console cache:clear --env=prod
Letting the web server build the cache resolved the problem. The command line environment must not be exactly the same as the web server php. On this server it is difficult to actually run command line scripts as the web server user.
Therefore, clearing the cache on the command line with no warmup is the work around:
php ./app/console cache:clear --no-warmup --env=prod
I'm pretty new to whole Grunt and SCSS workflow stuff and recently configured Grunt with a WP theme development that run under MAMP. Installation of Node, NPM, Grunt and its dependencies went smooth. However, when i make a change on .SCSS files, it doesn't seem to be reflecting the changes to the .CSS files due to following warning from compass:
Running "compass:app" (compass) task
LoadError on line ["55"] of /Library/Ruby/Site/2.0.0/rubygems/core_ext/kernel_require.rb: cannot load such file -- susy
Run with --trace to see the full backtrace
Warning: ↑ Use --force to continue.
Aborted due to warnings.
Not exactly sure what's up but obviously a communication issue between Ruby and Compass?
Whether it be incorrect version mapping or paths..?
I researched and attempted following:
Uninstalled the current and installed new Ruby
Installed RVM (didn't use it, just installed it)
Upgraded compass to the latest version 0.12.2 and made sure this version is reflected in package.json for grunt.
Any pointers and advise highly appreciated!
I don't know if this is an option but you might look at PrePros (https://github.com/sbspk/Prepros). I tried for a while to setup the raw/core setup you are working with but it was just always quirky - not to mention super tedious to setup. PrePros takes all the pain away! Just a suggestion.
Related/Reference link: https://stackoverflow.com/questions/19866550/sass-haml-compile-on-prepros
I followed sylius' install instructions for composer and got my local copy working. The issue is when I go to local/app_dev.php it takes an extremely long time to load, 12-18 seconds. however the profiler is showing a much faster time...
Also the installation instructions don't explain how to get local/app.php working or a production environment. Any information would be helpful :).
First let me thank #Florian for his link and the nudge to get me digging a little :).
When following the instructions on sylius' getting started page:
$ wget http://getcomposer.org/composer.phar
$ composer.phar create-project sylius/sylius -s dev
$ cd sylius
$ app/console sylius:install
you are by default installing using the config_dev.yml file. This will setup your db as {dbname}_dev, as well as have debug on in app_dev.php. When debug is on "cache files are dynamically rebuilt on each request." This is what is causing the slow speed.
In regards to using app.php(production env) you can run app/console sylius:install -e prod. This will setup a regular db and you can use app.php.
Mystery solved :).
Useful resource:
How to Master and Create new Environments - Symfony2
If you are on windows make sure to set your "realpath_cache_size" to at least 5M in your php.ini, as recommended by the SensioDistributionBundle. Like so:
; php.ini
realpath_cache_size = 5M
On my Sylius installation running in dev environment it reduced load times from ~15 s to ~2 s.
To further reduce your load times you might consider using WinCache https://sourceforge.net/projects/wincache/. I use the following settings while running Sylius with PHP's inbuilt web server:
; php.ini
[wincache]
wincache.enablecli=1
wincache.filecount=16384
WinCache seems to work just fine with Sylius's dev environment.
I was running Sylius on a Vagrant setup with default sync folder settings and found it extremely slow, up to 45 sec loads! Other Small Symfony projects weren't as bad so thought it was just Sylius, then I read that the synched folder settings on Vagrant are a lot quicker with the type NFS available on linux systems, it reduced from 40 to 4 seconds!
So if you're using Vagrant and find it slow make sure you set sync folders to NFS.
Sylius much slower then Symfony both in production and development mode although it is built on top of Symfony. The reason is its ResourceBundle. I'm sure there are methods to accelerate it in production but anyway it is very slow while development.
NFS will help you in vagrant case but still you can find it slow in bigger projects. Docker was even worse on MACOSX. If you are using Linux I think docker will kick ass for developemnt. Also if you are using PHP<7 move to 7.0 (upper versions have some issues with Sylius atm) and you will see huge improvement of performance even in dev enviroment.
Also give some more RAM to your Vagrant machine