I've been encountering a slew of issues with a fresh install of Laravel on Ubuntu recently but this latest one has me baffled. I was receiving the WSOD with zero errors in apache/php logs or laravel logs, despite having debug set to true and error display in PHP enabled. I updated the index.php file in public to add a die("Test"); line just to see if that was at least working.
It was, which was great - Test displayed on the site. However, now it won't go away. I've tried updating the text to something else, completely removing the line, etc., artisan cache-clear, composer cache clear and dump-autoload, and I've cleared out any cached items in the storage folders. I've cleared my personal cache and tried different browsers, also, so it's not a personal cache issue. I also tried restarting apache.
All of my chmod permissions should be correct at this point (bootstrap/cache is 755, all of the storage and subfolders are 755). I have had laravel write to the log for another issue (from CLI - a test I did just to make sure permissions were working) so that shouldn't be the problem.
I have this working perfectly fine in laragon on my local Windows machine but have had nothing but issues getting this guy up and running on this Ubuntu server. I have another prod instance of laravel that never gave me this much trouble, either, on another Ubuntu server (and usually it was just a permissions issue). Really not sure what to do at this point or what information might be useful. Hoping that someone else has run into something similar and can shed some light....
what kind of error show's the file /var/log/apache2/error_log?
what is the content of your laravel file storage/logs/laravel.logs?
how did you configure the vhost?
did you install laravel with composer?
give us more information please
Turns out the problem lay with the opcache PHP extension. This was enabled on all versions of PHP installed on my prod environment by default and wasn't something I was utilizing on my dev environment. Writing a test to clear opcache resolved this particular problem and I have since disabled the extension, as I was not intending to use it, anyways.
If anyone else runs into this problem and wants to disable, I simply went through WHM Easy Apache 4 and removed the opcache PHP extensions and then edited the php.ini files for all versions of PHP to set any opcache enabled type of flags to 0 (off).
Recently I started developing magento 2 projects.
First I tried on Windows with xampp and it was a mess... every refresh page was a nightmare, about 30-40sec to load the page. I read about it, that Windows system files is so slow working with magento because the large structure it has, and the article almmost was forcing you to use linux for developing on magento projects.
The problem is I need Windows for another company apps that only works on Windows, I tried to install a virtual machine with Virtualbox, it improved a bit... but the fact I'm working on a virtual machine pissed me off...
The next solution and I'm working currently, is using vagrant. Okay, I feel good developing on this way but it keeps going slow... 15-20s...
My config on Vagrant is 5120MB (pc has 8GB) and use all my pc 4 cores.
I'm feeling so bad working like this... when I was working on my previous projects, with symfony/Laravel/Codeigniter, was like:
write some lines of code, tab to browser, F5, INSTANTLY see changes.
On M2: write some lines of code, tab to browser, F5, wait... wait... okay now it refreshes the page, but it's not loaded, wait... wait... hmmm almost... okay. No changes but I cleaned the cache... ohhh I guess I had to remove static files too. Go for it... wait again...
God... There's no way M2 goes faster? I'm only asking 5s or something like that... it's just I'm feeling so dumb looking the screen waiting all the time...
For aclarations, I'm only asking for development mode, I tried had to install another project of magento on production mode for testing things faster and then it's okay fluid as hell compared with developer mode... because... omg... just try to do an order workflow again and again...
Well that's all... The only thing I didn't try is using Linux environment on the computer... but it's just the same as using vagrant... I don't understand... how are you developing M2 developers? in special frontend developers... I don't believe they are working the same way as me... waiting 20sec for loading the pages + cleaning cache + removing static files, etc.
Details: I tried everything with vagrant but don't improve, I'm currently on Ubuntu 15.04, Apache 2.4, PHP 5.6 (I tried 7 but still the same) mysql 5.6
This is the network tab:
http://i.imgur.com/HG7mbeX.png
2018 Update, Magento 2.2.4
Vagrant + Windows + Magento2 = disaster. Vagrant + Apple + Magento2 = disaster.
Ubuntu + Magento2 = cooking on gas.
Simple modules, e.g. a widget, take many days more than the expected 2-3 hours and it is not possible to remember what you are doing if it takes a minute to open a page, particularly so if you have to clear caches, compile, upgrade or anything else that should take no-time-at-all.
This I have experienced first hand, from working in an office where the options are Mac or Windows. After spending a whole day trying to change the template directive and failing to make one configuration change in 8 hours, I thought about giving it a go on a linux box to see if I had gone mad or if this Vagrant contrivance is as helpful as that drunken bum sleeping rough in the park down the road.
The aged linux box with anaemic RAM, an old SSD, stock Apache and no fancy cache things completed the task without problem, I was able to switch between developer and production modes effortlessly and get what had taken me days to not do done in minutes.
The work machine was 8th generation i7, the Vagrant setup was very much someone's baby and a lot of time had been spent building the beast. Yet tectonic plates move faster. Vagrant and virtualisation might be fashionable but it is no use for M2 development. In fact I installed M2 and did all the db and vhost setup for it in less time than it takes for a Vagrant box to build.
As for performance, since M2 on a basic linux setup is 10x faster than some clumsy Vagrant effort, it is easy to see where the real speed problems of Magento 2 are. If you fire up Lighthouse in Chrome you will see TTFB is absolutely fine but the performance halves if you minify and merge the JS + CSS. This is because M2 has a megabyte of scripts to download. This is the performance killer. If you are working on a Vagrant box then you will never see this and not have the speed to fix it. By fix it I mean write a proper theme that doesn't have nonsense such as jQuery loading on every page.
For production you need something that scales so you can get the normal speed enhancements going for that, e.g. Redis, opcode caching, Varnish, tweaked php-fpm, tweaked MySQL/MariaDB. If you are developing on Linux then you can test these things on localhost knowing they will work fine on production. With that abomination that is Vagrant you will be dabbling with these optimisations prematurely because you are hoping and praying for a performant machine because you need to get work done. However, in so doing, and with the absence of native speed, you will not get anything done.
If you don't have a spare machine to put linux on then just go to the local tip, get any PC, shove an SSD in it and you are good to go.
This is my recipe for developing themes/modules in localhost for Magento 2.2 and 2.3:
MacBook Pro
Valet Plus (Nginx, MySQL 5.7, PHP7.1 and 7.2 - you can easily switch between PHP versions with valet use 7.1 or valet use 7.2) https://github.com/weprovide/valet-plus
memory_limit set to 4G
Be sure Magento is set to developer mode: php bin/magento deploy:mode:set developer
ALL CACHES ENABLED except FPC. Whenever I need to test a change involving config files, etc I manually delete the content of the var/cache folder or the generated/code folder for DI changes. The cache type that specially slows down everything is the Configuration cache, so it must be enabled or the frontend/backend pages will load painfully slow.
I use Grunt Watch and the Livereload Chrome extension to see my changes to .less files without having to deploy static files with every change. https://devdocs.magento.com/guides/v2.3/frontend-dev-guide/css-topics/css_debug.html
Whenever I change a JS file I navigate to pub/static/[adminhtml/frontend]/[theme]/[locale]/ and delete ONLY the folder where the static file corresponding to the JS file I changed lives in. This prevents me from having to deploy ALL the static files. Magento will regenerate just the static files for the deleted folder saving a LOT of time (be sure to do a hard refresh in your browser every time you delete a static file)
It’s still not a perfect setup but it’s the fastest way I’ve found so far to be productive without pulling my hair out.
I tried everything and the only thing it works is the virtual machine that provides bitnami. https://bitnami.com/stack/magento/virtual-machine
Seriously, I don't know what has this vm, but goes really fast. I tried creating my VM using a fresh installation of Ubuntu, CentOS, etc. But doesn't work so fine like this VM.
If you work in developer mode you need to disable JS/CSS merge, disable xdebug and enable opcache. Feel free to run thes MySQL queries on your dev DB and flush cache. This will increate the site performance in developer mode.
UPDATE core_config_data SET value = '0' WHERE path = 'dev/css/merge_css_files';
UPDATE core_config_data SET value = '0' WHERE path = 'dev/css/minify_files';
UPDATE core_config_data SET value = '0' WHERE path = 'dev/js/merge_files';
UPDATE core_config_data SET value = '0' WHERE path = 'dev/js/minify_files';
UPDATE core_config_data SET value = '0' WHERE path = 'dev/js/enable_js_bundling';
UPDATE core_config_data SET value = '0' WHERE path = 'dev/static/sign';
Try to disable synchronisation with default vagrant sync folder (just comment config.vm.synced_folder in VagrantFile and reload) - it's to slow when need to work with a lot of files...
Also in developer mode will be useful to generate static files:
bin/magento setup:static-content:deploy and ensure that all caches are enabled: bin/magento cache:status
If it don't help you can try Magento DevBox tool based on Docker: http://devdocs.magento.com/guides/v2.1/install-gde/docker/docker-over.html
In "developer" mode, all caches were disabled.That why magento become slow.
I suggest to enable caches by execute command
./bin/magento cache:enable
However, you need to clean cache ./bin/magento cache:clean every time you modify xml files or configurations.
my recipe:
Use *nix as your main OS
Use docker with PHP 7 and Nginx
use gulp for generating css and js (faster than grunt)
use redis and varnish
disable only needed caches
And the most valuable advice - you really need SSD to work with magento2 if you still trying to develop on HDD
p/s Magento 2 more complicated than Symfony/Laravel/CI (M2 consist Symfony
by the way) and can't be so fast as pure frameworks
For production environment:
You must use Redis for handle Cache, Full Page Cache et Session
(http://devdocs.magento.com/guides/v2.0/config-guide/redis/config-redis.html)
You must use Varnish for HTTP cache built in with Magento
(http://devdocs.magento.com/guides/v2.1/config-guide/varnish/config-varnish.html)
You need to set up production Magento mode.
(http://devdocs.magento.com/guides/v2.1/config-guide/bootstrap/magento-modes.html)
You must use ElasticSearch for search engine, EE only
(http://devdocs.magento.com/guides/v2.1/config-guide/elasticsearch/es-overview.html)
You must use PHP 7
You may use MariaDB even if it is not supported by Magento 2.
You must use CSS minification and JS minification and JS bundling (which works only on production mode).
Check the official Magento 2 documentation in order to set up this production configuration.
A bit late here but i think the answer while working on vagrant / docker is mostly that the I/O of files is terribly slow.
My solution was simply do disable the whole shared folder and replace it with a remote project (sftp connection) in PhpStorm. All files are so stored within the virtual machine and don't have to be synced everytime the page needs a reload.
The main benefit of course is, that it is amazingly fast while working on developer mode.
But also there are some minor problems while working with this setup:
You can't run commands straight from your terminal. You have to ssh into your vagrant for running magento2 cli commands.
After running composer updates you may have to download the whole folder again, because in PhpStorm remote changes are not downloaded automatically.
I made this vagrant which allow you to customize mount options and has great performance:
nfs mount or regular mount
directory mount /var/www/magento/app or whole project /var/www/magento
https://github.com/zepgram/magento2-fast-vm
You can work on a fast magento installation and adapt parameters depending on your work practice and your host machine perf.
For example, if your host machine doesn't support NFS option and has bad performance you can mount only app directory which is enough for development.
#Henry's Cat is right. Non linux os + Magento2 = disaster.
If you are not working hard with xmls you can turn on magento cache
bin/magento cache:enable
and use bin/magento cache:clean when you modify something in theses files
or better just disable certain cache types bin/magento cache:disable db_ddl full_page . #Igor Sydorenko is absolutely right, disabling css js merging/minifiying will IMPROVE A LOT developer mode performance.
In order to give flexibility to developers, Magento generates a lot of files. If it runs in production mode, the slowest part is the disk read which can be optimized.
But while running Magento 2 in developer mode, disk read and write operations make it too slow.
I was also experiencing the same while developing Magento 2 applications. My first suggestion is to move to SSD. However, it is not possible for every everyone every time.
It was also not possible for me to install SSD in my high-end laptop with lot of RAM and CPU power.
I found a work around which made my development considerably fast in localhost using Redis cache. Cache cleaning and warming became extremely fast which reduced my waiting time drastically to see the changes. Here is the full article to use Redis cache in localhost with Magento 2.
Ok so i have been working with Magento 2.2.7 from approx 6-8 months . so there are some notes you should consider :
1. use SSD Hard Disk (if possible)
2. configure grunt in magento. it will surely help to make frontend devlopment in magento fast. because grunt helps to compile less file without need of executing s:s:d command.
grunt with magento
3. do not enable xdebug.
4. disable cache only if you are reloading page too many times in a row.
I tried many machines and many configuration like:
Windows 10 - vagrant machine debian
Windows 10 - vagrant machine debian - docker
Windows 10 - vagrant machine ubuntu - docker
Windows 10 - vagrant machine ubuntu
The problem of bitnami machine : not realy easy to be configured for Xdebug
In my experiance the Best one is a vagrant machine for those who want to work on Windows:
https://app.vagrantup.com/certiprosolutions
So use this config on your Vagrant file:
config.vm.box = "certiprosolutions/ubuntu-lnmp"
config.vm.box_check_update = false
# box modifications, including memory limits and box name.
config.vm.provider "virtualbox" do |vb|
vb.name = "Magento 2.3.3 ubuntu ngnix"
vb.memory = 8240
vb.cpus = 2
#vb.customize [ "modifyvm", :id, "--uartmode1", "disconnected" ]
end
The advantages:
you can switch between many configuration of PHP
(5.6,7.0,7.1,7.2,7.3)
work on many version of Magento in the same environment
A little note. to make xdebug work you should change the configuration of xdebug to that:
[XDEBUG]
zend_extension=xdebug.so
xdebug.default_enable = 1
xdebug.remote_enable = 1
xdebug.remote_connect_back = 1
xdebug.remote_autostart = true
xdebug.remote_handler = dbgp
xdebug.remote_port = 9001
xdebug.remote_host=127.0.0.1
xdebug.remote_log="/tmp/xdebug72.log"
;xdebug.max_nesting_level = 1000
I just installed both Symfony2.4.4 and Symfony2.5.1 and set up a hello world page + some basic things I use (assetic js/css management etc). Configuration and setup for both projects are exactly the same.
I noticed that in app_dev the Symfony2.5.1 needs around 1100ms to generate the page, while Symfony2.4.4 only needs around 130ms to generate the same page. Both numbers come from the Symfony debug toolbar.
When I take a look at the profiler's timeline I noticed Symfony2.5.1 uses around 900-1000ms for something called "Initialization time", while with 2.4.4 that only takes 50-60 ms.
Symfony2.5.1
Symfony2.4.4
Does anyone have an idea why it takes Symfony2.5.1 so much longer to initialize the project? I've checked the changelog for 2.5.x but haven't found anything so far. (https://github.com/symfony/symfony/blob/master/CHANGELOG-2.5.md)
Edit: Apparently the 2.5.1 rebuilds the entire dev cache on each page load, while the 2.4.4 does not. Not sure why.
Edit2: Noticed the chromehelper on my mac was running rogue (eating CPU), so I restarted the browser. Afterwards 2.5.1 doesn't rebuild dev cache anymore and load times are similar to 2.4.4. I don't get how it can be related though, how can a rogue browser influence the rebuilding of dev cache? FYI: The 2 projects are running on a virtualbox with centOS on that same mac.
The initialization time difference between both version was happening because Symfony2.5.1 was completely rebuilding its dev cache every time I loaded the page. I 'solved' it by killing off my mac/chrome browser which was running rogue.
After browser restart, 2.5.1 cache behaved the same as 2.4.4, with loading times around 130ms.
How a rogue browser can influence dev cache, I have no clue though.
The problem is when I open any Magento page in browser, including /admin, it doesn't load properly and keeps loading forever. No files where changed - yesterday it was working, today it stopped working.
Can anyone recommend how to debug it? And what might be the reason for this?
There are no any errors in logs, php works fine, we tried rebooting server.
Thank you.
there wont be any errors unless you have low server resources, or maybe you have some content from external servers that probably down right now. first quick debug - open page in chrome and inspect element, you will see what slows your page. or you can check top, no IO problems, enough RAM, no processes running with >100% CPU?
rebooting server never fixes your problems. check if you have cache enabled.
not much information here to tell you exactly whats going on.
I recently ran into this problem too. My Magneto 2 site (on Ubuntu 16.04) worked fine one day and then would continuously load the next. Cleaning the cache and deleting/rebuilding static files made it work briefly, but it would go back to not loading the pages within a few clicks... even the admin.
My fix happened to be that the disk was full. I didn't realize it until I went in command line and updated composer which kept giving me a disk full error.
I switched to the desktop on Ubuntu and ran a disk analyzer, which pinpointed exactly where all my space was being used.
gksudo baobab
I didn't have gksu installed, so I had to install it first by typing:
sudo apt install gksu
It turns out I had backups that had not been deleted. Large tar files that I no longer needed.
I hope this helps!
Edited to include which OS I am using.
I have run into problems getting my local php and rails development environments to play nicely with each other on OSX 10.7.
Developing is a hobby, and I am a total noob. I use MAMP for developing in PHP. A few months a ago I decided to give RoR a whirl, and set up a dev environment using Passenger.
A couple of weeks ago I reinstalled MAMP when I noticed I could not access the MAMP sites.
Now I can't access the RoR sites. I've tried reinstalling Passenger. I still get the error "Oops! Google Chrome could not find app.local" when I type the local URL. If I navigate to localhost, I get an "It Works!" page, so something is being served.
I have experimented with Pow. The server seems to work if I navigate to localhost, but when I go to the app I get a rake not found error. Strange, as all the gems worked under Passenger. I've since uninstalled Pow.
So I have three questions.
1) How do I troubleshoot my setup to find out what is going wrong? I'm guessing it is an issue with the Apache server (though I could be very wrong). Where should I look for log files to help resolve this?
2) What is the best way to set up a local dev environment so that I can switch easily between RoR and PHP? (I know that virtualization is an option, but would prefer not to go down this route, unless there is a very good reason to).
3) Can anyone recommend a good guide or source of info for beginners on setting up dev environments? I have read a lot of different things online, but need to get a better grasp of the basics - i.e., understanding where gem files etc are being installed, proper use of bash files, macports vs homebrew, passenger vs pow etc.
Thanks for taking the time to help a frustrated beginner.
Andy
OK, I'm going to answer my own question. I have got the rails apps running locally, but I still don't feel confident that I fully understand what's happening.
This is what I did.
Uninstalled Passenger
gem uninstall passenger
Uninstalled Passenger PrefPane by right clicking in system preference.
Updated all system gems
gem update --system
cd'd to app directory and updated all app gems
bundle update
Reinstalled Passenger
gem install passenger
passenger-install-apache2-module
Recompiled Passenger Prefpane for OSX 10.7 using xcodebuild and installed.
Deleted and readded apps to passnger prefpane.
I'm not sure what fixed it, but the apps are now running. This is what I think happened. Somehow the configuration between Passenger and Apache had become corrupt, and reinstalling prefpane added the correct lines back into the Apache config file.
The problem is that I stil don't know which Apache install Passenger is using- mac default, macports, or MAMP. I think this is what confused me before, as the config file I was checking was not the correct one.
As a byproduct, I have learned that several of my gems were not up to date or missing dependencies. This may explain the difficulties I experienced with Pow. If so, the Pow seems to be a much easier alternative to Passenger.
So, things are up and running, but I still have a long way to go before I understand how all these configuration files a working. I still don;t think I'm using the Apache install that I would prefer to use!
EDIT
PS: MAMP is also still working for PHP development, and I can easily switch between the two by disabling web sharing in system preferences, and launching MAMP. So all issues resolved for now!