Empty Frames in betas 34-35
klaxian opened this issue · 12 comments
Beta 34 and 35 do not work at all for me. The navigation and primary frames appear empty. There is a 500 server error returned when attempting to load intro.php, which does not appear to be coming from apache. Issue #122 was never resolved and beta 35 made it worse. beta 33 still works normally.
Are you running on windows or linux?
Is your temp folder universally editable?
You could try running make install from the project root, to make sure temp folder and subfolders are writable.
I see several things that could explain the absense of logs:
- When debugmode was enabled, I was enabling php_console but this will prevent errors from displaying if you're not using chrome or don't have said chrome extension enabled. Now I'll use an explicit setting in
config.inc.phpto enable it, and disable the extension otherwise. - I was setting the error log path to a subfolder inside
temp. If temp is not writable, not only will preventTwigview engine to create its cache, but also will prevent creating or writing to said error log. Now the error log location will only be set if explicitly defined inconfig.inc.php
I also added an error message to display beforehand if temp folder is not writable, as well as enabling Slim Framework setting displayErrorDetails when $conf['debugmode]` is true.
Finally, I added composer's post-install scripts to chmod the temp folder. Not sure if this will work ok on windows tho.
The comment you see in the top of some classes is automatically inserted by php_cs_fixer. I added said tool to the build step before releasing a new tag, to ensure said comment is always up to date.
Please upgrade to the latest version.
My temp directory (and sub-directories) was already universally editable (777). After upgrading and running make install, the navigation frame now contains the phppgadmin logo and a perpetual spinning "loading" icon. The main frame is still empty. I will enable the new debugmode setting and examine the logs.
I did notice that the following command in the Makefile needs to be prefixed with sudo: chmod 777 temp -R.
After your latest changes, I am able to provide a stack trace for the errors that I'm getting. I tried to debug this a little, but you are more familiar with the code than I am. I do have a server configured and everything still works normally if I revert to beta.33. Let me know if you need anything else.
PHP Fatal error: Uncaught Slim\Exception\ContainerValueNotFoundException: Identifier "server" is not defined. in /var/www/phppgadmin-hf/vendor/slim/slim/Slim/Container.php:120
Stack trace:
#0 /var/www/phppgadmin-hf/vendor/slim/slim/Slim/Container.php(172): Slim\Container->get('server')
#1 /var/www/phppgadmin-hf/src/xhtml/HTMLController.php(89): Slim\Container->__get('server')
#2 /var/www/phppgadmin-hf/src/xhtml/HTMLNavbarController.php(155): PHPPgAdmin\XHtml\HTMLController->getActionUrl(Array, Array, 'PHPPgAdmin\\Cont...')
#3 /var/www/phppgadmin-hf/src/controllers/BaseController.php(234): PHPPgAdmin\XHtml\HTMLNavbarController->printTabs(Array, 'intro', false, 'PHPPgAdmin\\Cont...')
#4 /var/www/phppgadmin-hf/src/controllers/IntroController.php(45): PHPPgAdmin\Controller\BaseController->printTabs('root', 'intro', false)
#5 /var/www/phppgadmin-hf/src/controllers/IntroController.php(24): PHPPgAdmin\Controller\IntroController->doDefault()
#6 /var/www/phppgadmin-hf/src/views/intro.php(13): PHPPgAdmin\Controller\IntroController->ren in /var/www/phppgadmin-hf/vendor/slim/slim/Slim/Container.php on line 120
Are you sure you've got your rewrite rules right? Container's attributes server database and schema are set in a middleware that runs before routing. Therefore, if they are not set, the only explanation that comes to me is you're loading a php file directly.
Can you check your browser's console requests to check what scripts are you requesting?
The intro screen should be loading:
http://phppga.server/src/views/intro
instead of
http://phppga.server/src/views/intro.php
I'm uploading a new tag where I set those properties to null if they are not set in the request. However, I was hoping to get rid of $_REQUEST and other superglobals eventually.
My rewrite rules match .htaccess in the repository. It looks like there is only a single rule to rewrite an empty path to index.php though. Am I missing other rules?
The browser console shows that /intro, /jstree, etc are being requested (not *.php). The only message in the JS console is 'Will not pushState with Method ""', but I think that is expected.
Your latest changes have allowed the main frame to initially appear normally, but digging deeper into tables, views, etc. reveals many errors like the following. It is not usable.
Notice: Undefined index: server in /var/www/phppgadmin-hf/src/classes/Misc.php on line 676
Call Stack:
0.0001 367200 1. {main}() /var/www/phppgadmin-hf/src/views/tables.php:0
0.0074 971112 2. PHPPgAdmin\Controller\TablesController->render() /var/www/phppgadmin-hf/src/views/tables.php:13
0.0074 987576 3. PHPPgAdmin\Controller\TablesController->doDefault() /var/www/phppgadmin-hf/src/controllers/TablesController.php:121
0.0107 1545128 4. PHPPgAdmin\Controller\TablesController->printTrail() /var/www/phppgadmin-hf/src/controllers/TablesController.php:146
0.0108 1548824 5. PHPPgAdmin\XHtml\HTMLNavbarController->printTrail() /var/www/phppgadmin-hf/src/controllers/BaseController.php:216
0.0111 1552184 6. PHPPgAdmin\XHtml\HTMLNavbarController->getTrail() /var/www/phppgadmin-hf/src/xhtml/HTMLNavbarController.php:34
0.0113 1553376 7. PHPPgAdmin\XHtml\HTMLNavbarController->getHREFSubject() /var/www/phppgadmin-hf/src/xhtml/HTMLNavbarController.php:420
0.0113 1553376 8. PHPPgAdmin\Misc->getSubjectParams() /var/www/phppgadmin-hf/src/xhtml/HTMLNavbarController.php:380
The navigation bar still only displays "Loading...".
Sorry, I misread the rewrite rules. It looks like everything is being redirected to index.php. I verified that this is working by echoing a test statement in index.php. The rewrite appears to be working correctly, but server and others are not being set with betas after 33/34.
What is the url you're requesting on the browser?
I'm starting to think that there is something missing from the current .htaccess I have as example. For example, the nginx config is passing the arguments from the query string, but perhaps apache isn't, and that's where the problem lies.
Besides, I can see you're requesting tables.php which shouldn't happen. No php file from views folder should be ever requested, I keep them in place because of the tests. Perhaps apache is trying to append the php extension or something?
I'll install Apache to dig deeper.
Can you look at the response from the jstree endpoint? Perhaps it's requesting the php view directly...
You could also try renaming the views folder to something else to force Apache to resort to index.php
I still wonder if it's passing the query string parameters to the slim router.
What makes you think the browser is requesting tables.php? That file is listed in the backtrace because it contains the {main}, but the browser is not requesting that page explicitly. I tested to make sure index.php is called for each request. I reviewed the browser console again. There are NO PHP files explicitly requested. Aside from JS and media, I only see requests to views/intro and views/jstree initially, which are redirected to index.php. Also, it looks like Apache is preserving the URL query string because I'm seeing requests like views/browser?action=tree&json=true when I click around in the main frame. However, I don't see any query strings for views/jstree. I don't get the "undefined index" notice until I select a specific database, but the tree navigation frame never loads.
Everything used to work normally around beta 33. All versions after that have been mostly unusable for me. I'm not familiar with the "slim" framework, but are you sure all the query string variables are being passed between scripts correctly?
Renaming the views folder resolves this problem. Good idea! With the rewrite rules in .htaccess, I don't think Apache will rewrite a directory that exists. I think we need different rewrite rules if you want all requests to be redirected to index.php.
good to know! I'm experimenting with apache in my local machine right know and I noticed a weird behavior in the jstree frame, in which it appends every data item of the node to the query string. It seems it was overkill to add a data atribute to the nodes. I'll be releasing a new beta tomorrow.
Ok I'm closing this issue for the time being. Please keep me up to date with any bugs you run into. I'm doing some heavy lifting and your issue filing has been really helpful.