Closed puschie286 closed 7 years ago
Does it works when you disable German ? Or does it also fail on a blank install on that PC as well ?
@puschie286 any news on this ? Is it still happening ?
My first inspiration would be this is related to memory. So even though the German extension was installed it would matter little, one could replace that with any other extension and run into the same issue due to the dependency analysis composer does in the background.
Based on that;
hey, sry for late response - currently i havent the time to test it - i will try it next week we have assign 1G memory to php, so it should be not the problem
hey, i tired different things and it looks like that composer is the problem - its extremly slow, a single plugin installation ( via cmd ) can take several minutes, so i guess that is the problem. ( i also notice that the bazaar memory icon show the wrong amount of memory )
Hi, sorry to hear that. It's true that Composer is resource-hungry and might now work correctly in all setups.
@puschie286 i also notice that the bazaar memory icon show the wrong amount of memory
That's an odd issue. Could you share the setting you have in your php.ini
and what value Bazaar shows ? And what webserver are you running ? Thanks.
i just change the "memory_limit" line in php.ini ( tried with 1024M, but switch back to 256M ). Bazaar shows the default value 128M i use php7.1.8 and apache 2.4.25-3
There are different php.ini's? For the one in use by apache you'd need to look at: /etc/php/7.1/apache2/php.ini
. The output of php -i | grep ini
will point to the ini file for cli only.
Also, if you have the correct ini, only a reload of apache will bring the changes into effect: sudo apache2ctl graceful
I'm pretty sure Bazaar is correct in figuring out the configured memory limit. Otherwise it would show no value instead.
well i changed the php.ini you mention - and of cause had restart apache the cli php.ini has the default value of -1.
hmm, i checked the bazaar memory icon again and currently it shows the correct value - maybe it was cached by my browser
That might be possible 😁
So the problem with the loading screen is caused by a javascript error. If it still pops up could you check the console tab of your browser (eg under f12).
Steps to reproduce
( some times | i guess after a cache clear )
Expected behaviour
after a short loading time a list of extensions should be shown
Actual behaviour
after some minutes of loading ( and waiting for web request to complete ) -> the page stuck at 'is loading...' ( Wird geladen... ) screen | after about 4min ( 234012ms ) the request anwser was recived and the result is shown
NOTE : no entry was added to flarum.log during the request
Configuration
Debian 9.1, everything is up to date
Flarum core 0.1.0-beta.7 PHP 7.1.8-2+0~20170804100530.7+stretch~1.gbpae7f04 Loaded extensions: Core, date, libxml, openssl, pcre, zlib, filter, hash, pcntl, Reflection, SPL, session, standard, mysqlnd, PDO, xml, bz2, calendar, ctype, curl, dom, mbstring, fileinfo, ftp, gd, gettext, iconv, json, exif, mysqli, pdo_mysql, Phar, posix, readline, shmop, SimpleXML, sockets, sysvmsg, sysvsem, sysvshm, tokenizer, wddx, xmlreader, xmlwriter, xsl, zip, Zend OPcache EXT flarum-bbcode v0.1.0-beta.5 EXT datitisev-dashboard v0.1.0-beta.6 EXT cbmainz-de 0.7.1 EXT flarum-english v0.1.0-beta.7 EXT flagrow-bazaar 0.2.4 EXT flagrow-upload 0.5.7 EXT flarum-lock v0.1.0-beta.7 EXT flarum-markdown v0.1.0-beta.5 EXT flarum-mentions v0.1.0-beta.7 EXT flarum-sticky v0.1.0-beta.7 EXT flarum-subscriptions v0.1.0-beta.6 EXT flarum-tags v0.1.0-beta.8 Base URL: http://192.168.100.253/flarum Installation path: /var/www/html/flarum