An old topic, but new symptoms

To avoid the heartbleed vulnerability, I installed the latest version of XAMPP (1.8.3-4).
However, I now cannot get Limesurvey to work any more -- I just get a blank page when I go to .../limesurvey/admin. The version of limesurvey which I am trying to use is 2.05+ build 140915.

To get some idea of what is going on, I tried setting debug to 1. I get a PHP warning which seems related to Yii -- see the first attachment.

The second attachment is the output from XAMPP's PHPinfo() function. To me it looks quite normal, but maybe limesurvey has requirements which I don't know about...

Any help would be much appreciated!

Robin

I have tried to investigate this a bit more.
The error arises because the file LSHttpRequest.php cannot be found. However, there is a file with this name in the system, namely in the web surver (htdocs) sub-directory /limesurvey/application/core

So what is going wrong here? It seems the path used to find the file is incorrect. Now, I assume that the path is derived from basePath in some way (I don't have enough detailed knowledge of the limesurvey system to know exactly how). In thye simple way of sewtting up limesurvey, the base path is worked out in config.php, and apparently should be one directory "higher up" than the directory in which config.php is found. Now config.php is in the directory .../limesurvey/application/config, which means that basePath should be set to .../limesurvey/application

However, I have been folliwng the installation security instructions at www.limesurvey.org/manual/Installation_security_hints , which suggest just using .../limesurvey as the basePath. This seems not to be a good idea, and this explains why the error arises, I guess.

However, finding a proper solution is not easy. The good new is that if I set basePath to .../limesurvey/application, the file LSHttpRequest.php gets found

But then it all goes wrong again. and I get a new PHP message, which I attach. This doesn't look good at all -- it looks as though the whole PHP setup no longer hangs together coherently. I think I need a real expert in LS's architecture to find the real root of the problem.

Hope someone will help...

Many hopeful regards
Robin

robin_sharp wrote: But then it all goes wrong again. and I get a new PHP message, which I attach. This doesn't look good at all -- it looks as though the whole PHP setup no longer hangs together coherently. I think I need a real expert in LS's architecture to find the real root of the problem.

Seems your LimeSurvey DB is not installed.

Please : remove application/config/config.php, and launch the default LimeSurvey installation.


For : www.limesurvey.org/manual/Installation_s...s_of_config.php_file you need to do it only after installation, and it's not a great security issue, only of your webserver have another security bug/issue.

Denis

Thanks! I didn't realise that the "extra security" should be applied after the default installation.

However, things still don't seem to work as they should in the default installation. Going to the default LS installation, I get (as expected) the installer web page, but in step 3 of the installation procedure ("Pre-installation check"), the installer complains that the /upload directory is "Found & Unwritable". All the other checks are OK.

This is quite a mystery. I am using a Linux OS (Ubuntu, to be precise), and the /upload directory has exactly the same permissions as the /tmp directory, and so do all its files. Setting the permissions to Read&Write for everybody (owner, group and world) has no effect on the result of the check.

Robin

Oops! The previous observation is my own fault. Clearing the cache solved the problem.

This enabled me to carry out the pre-installation check properly, and to set up the database.
Once the installer had detected that there was already a "limesurvey" database with suitable tables, I was re-directed to the admin page. Here I (once again) faced a blank page.

I have tried setting debug to 1 in the config.php file set up during the installation. The result of this was the PHP Notice which I have attached. Once again, the problem is flagged as an attempt to get a property of a non-object. So I feel I'm back where I started

Hoping for some new advice
Robin

I have now looked carefully at the PHP code, especially in InstallerController.php, and at the content of the database. There seem to be two bugs:
1.

1. An underlying bug in MySQL as set up in XAMPP. It uses ISAM tables, so each table in the database should have a .frm file describing its column structure. For the database "limesurvey", these files all lie in the directory ...lampp/var/mysql/limesurvey (On my computer "..." is /opt, but I guess this varies from one setup to another.)
   
   Unfortunately, the setup somehow makes it possible to get into a state where a table contains nonsense in its .frm file. Any action on this table -- even trying to delete it or create it -- will then cause MySQL to report that the table does not exist. This unfortunate property has been seen in earlier versions of XAMPP.
   
   Several solutions seem possible. Of course, I shall report the bug to ApacheFriends and Oracle. But anyone experiencing the problem here and now, I believe, can use a simple fix:
   • Delete the .frm file for the table which has the problem
   • Restart MySQL
   • Log in to your MySQL server as the root user and create the table (the descriptions are in the limesurvey directory ...limesurvey/installer/sql/create-mysql.sql).
   After this, normal use of the limesurvey system can continue.
2. Limesurvey itself has a bug which hides the bad state of the database tables. In the file InstallerController.php, lines 295-298, there is some code which claims to check whether the database tables are present. However, it only checks whether the "lime_users" table is present. This is not enough to reveal the situation resulting from the XAMPP/MySQL bug. The fault which I experienced "Trying to get property of non-object" appears because the tables "lime_plugins" and "lime_plugin_settings" were corrupted. I have now used the fix described above, and the limesurvey system now starts quite normally.

Phew... That took some time to discover. Would you like me to file a bug report for the missing checks in limesurvey itself?

Robin