I have a problem with the Installation of LimeSurvey.

After a successful configuration and after a successful pre-installation the installation screen appears for a few seconds (see screenshot "LimeSurvey after Installer").

After that I only have a white screen: energieagentur-obb.de/limesurvey/admin/

The debug-mode shows a problem with the database, missing table "settings_global" (see screenshot).

I use WordPress 4.9.8

What can I do?

If I get the infos right, you installed LimeSuvrey inside a Wordpressinstallation.
That will cause a lot of trouble, cause both applications (Wordpress and LimeSurvey) are rewriting URLs of the webserver.

If you have Wordpress in your webroot, you better buy an additional webspace or think about reorganizing your current webspace (e.g. webroot/wordpress/ and webroot/limesurvey/ side by side).
Perhaps your webaccount allows you to setup subdomains on subdirectories (umfrage.meinedomain.tld).

If you still want to install LimeSurvey inside a wordpress directory, you will have to edit htaccess files by hand and check after every update what changed. I cannot recommend that. It's begging for trouble.

Thank you for your answer and your advice.
I have just set up a subdomain and installed limesurvey there.
But it is exactly as before: a white screen
In debug-mode also the same massage: missing the table settings_global in database (see previous screenshot)
Is that perhaps a problem of strato?

If it is within a subfolder of the wordpress installation, I so far never had problems.

I am currently running wordpress under the domain and then Limesurvey 3.x in a subfolder.

Wordpress: domain.tld
Limesurvey: domain.tld/subfolder/

Looks pretty much like this with the folder "s" containing Limesurvey and you can see the files and folders from wordpress. Never had problems with installation. Of course, if you don't install it in a subfolder,...



My other LS installation is in a subdomain. However, the structure is basically the same. When I create a subdomain, the system just creates a subfolder for this account. So survey.domain.tld just is a pointer to domain.tld/survey/

From your screenshot I am seeing that you had already a database with limesurvey tables before and you made the new install on top of this?

Do a clean install in a new database and see what happens.

holch wrote: If it is within a subfolder of the wordpress installation, I so far never had problems.

That depends on the contents of the .htaccess files on the different levels.


Strato offers different kinds of hosting packages. If you have a special wordpress hosting package, there might be other rules placed into the .htaccess webroot. That is just a guess.

Joffm is using Strato with LimeSurvey. He might join this thread and offer some first hand experience.

I would like to thank all those who have given me advice in this matter!

It worked!

The solution was the installation of LimaSurvey in a subdomain and the creation of a separate database.

For those who have the same problems with STRATO, I would like to clarify the correct configuration here:

database location: rdbms.strato.de
database user: Uxxxxxxx (where x is replaced with you User-name)
database name: DBxxxxxxx (see above)
table prefix: lime_

This configuration worked on my installation.

Thanks again to all who helped me!

Best wishes, Michael

That depends on the contents of the .htaccess files on the different levels.

I make no changes to the .htaccess of Wordpress or Limesuvey. Vanilla install. No problems so far.

holch wrote: I make no changes to the .htaccess of Wordpress or Limesuvey. Vanilla install. No problems so far.

I got that. I would be able to do that too. But people like simple rules of thumb. Your wordpress installation may differ in terms of plugins to other wordpress installations. The webserver can overrule certain htaccess rules. E.g. was LimeSurvey preventing Let'sEncrypt cert checking when installed in webroot. htacess rules were tighten and bingo. Exception for .well-known forgotten. If you have a provider which enforces that on the webserver level this issue isn't occuring.