Unable to change the /log folder (1&1)

1

Hi,

On a website that has been running for a while without problems, the latest grav update resulted in an error (/logs not writeable).

Problem is that 1&1.de does not allow to chown/chmod the log folder. Hence i’ve opted for the suggested cookbook solution (https://learn.getgrav.org/cookbook/general-recipes#override-the-default-logs-folder-location).

I created the setup.php file as well as a grav-logs folder. Even if i set the permission on the grav-logs folder to 777 the original error remains and it seems the system is still trying to write to /logs rather than /grav-logs.

Since i also can’t login to the admin panel anymore, is there a way to clear the cache or could there be an other issue?

Thanks,

Laurens

2

You should be able to clear the cache by running the following at the CLI.

bin/grav clear-cache

Some general thoughts on troubleshooting are given below.

That’s strange that 777 isn’t working for the writes. We do want to avoid 777 if possible. I doubt it would be a cache issue (as it would have to be caching the PHP unless the file is being referenced by Twig and that Twig is cached, not sure on this part), but if you clear the cache, does it work (that is, accept the new PHP file’s changes)?

If you adjust the core file, does it change what the log write location is?

Can the install write other files to the server (posts, etc.)?

To make sure, everything is spelled correctly, right?

Some other thoughts in terms of the environment:

Is suhosin being utilized by the host?

What’s the directory’s ownership?

Is the server Apache? If so, which PHP handler? Is it running Nginx or Litespeed? Is the web service running as your user or as a web user (www-data, nobody, or your site’s owner’s username)?

Do you have plenty of disk space?

What’s the actual error being reported? Is there anything reported in a PHP error_log or error.log file? What about the web server’s error log?

3

Hi,

Thanks for your suggestions.

Below is the error that is shown:

Screenshot from 2018-01-07 11-47-17
Screenshot from 2018-01-07 11-47-17.png833×89 5.08 KB

Below is the actual content of the setup.php (copied from cookbook)

<?php use Grav\Common\Utils;

return [
‘streams’ => [
‘schemes’ => [
‘log’ => [
‘type’ => ‘ReadOnlyStream’,
‘prefixes’ => [
‘’ => [“grav-logs”],
]
]
]
]
];

The actual folder Grav-logs has its permission set to 777 (just for testing purpose ofc.). The owner is www-root.

I just checked, unfortunately the webhoster does not allow for SSH access. Server is running PHP 5.6.32 & Apache with CGI/FastCGI.

The actual setup.php is read upon opening the page. When i add phpinfo(); to the setup.php file i get all the php info upon reloading the page.

  1. Setup.php is read and executed
  2. Change in log folder is completely ignored
  3. regardless of what i change the new log folder to, the above error remains the same.

I also tried changing the folder directly in the Common > Config > Setup.php, without any effect. Same error is shown.

4

I just tested this on my Grav site; it worked without an issue. (Ubuntu 16.94, Nginx 1.13.7, PHP-FPM 7.0.22) Given that, I’d say the documentation is still spot on and I would be more prone to questioning something in the server’s or site’s configuration. I’m guessing this is a shared host if you don’t have SSH access. Are you using a control panel (cPanel, Plesk, etc.) or just FTP/FTPS (since you don’t have SSH, that should mean you aren’t using SFTP, though FTPS could still be a thing).

I want to make sure I am understanding you and to clarify we are on the same page: when you say phpinfo is being displayed after adding code to the file, you are adding it to a file called “setup.php” which exists inside of /homepages/40/d564426001/htdocs/, correct?

If so, then we at the very least know that the file is being read and Grav is either not processing the variable change, or something is not letting the change be made on the host.

I want to narrow this down to one or the other.

When you say the latest Grav update spawned the error, did you update the site to Grav v1.3.10? What version did the site update from? Were there any other changes with the update? Given that it was working fine before the update, this would strongly imply to me something site-side rather than server-side, as the server was letting the log files be written to until the update. The change to 777 shows it is not ownership/permissions related, and the Apache/FCGI setup is pretty standard. I’m surprised the site would beginning as www-root rather than a user if it is a shared host, but beyond that, it sounds normal.

Are you using any Grav plugins, have you made any changes to other Grav source files or to the site’s config, or is this a relatively clean install? (I killed my site for a time by disabling a single option and only managed to get things running once I turned it back on again; it’s why I ask.)

Would you be able to test a fresh Grav install of the installed version to see if it persists there in a subdir?

A common troubleshooting technique with WordPress is to disable any and/or all plugins. Is there perhaps a caching plugin at work?

Are you using Memcache or any of the other caching options?

Can the site create posts/pages?

5

You could empty the cache folder manually. Just delete the things in it.

6

Hi @thwright

I am having exactly the same issue as @laurens1991 - I am also on 1&1 hosting.

I had Grav working on my local environment, but as soon as I moved over to 1&1, I get the same issue with the logs directory permissions. So I followed the instructions as per the Cookbook and yourself, but to no avail.

Have you got any other ideas? Any help would be greatly appreciated.

Thanks Steve

7

Just received a notification that someone replied on this thread. First of sorry @thwright for not getting back in between. I got crazy busy and didn’t have time to trouble shoot properly, mainly as the page had to go live again asap.

@poomv2 I ended up disabling the problems plugin. That was the only way i got it to work. I even did a complete new install on the server.

After a bit of trail and error i ended up with a internal server error, which on its turn I could fix by following the advise in the following thread:

One option that i still want too try is install grav in a subdirectory so it doesn’t conflict with the 1&1 default folders.

Why or how its possible that the changes to setup.php are completely ignored i do not know. Hopefully the above helps you to at least get your site online again.

Other than that i can only advise to stay away from 1&1 shared hosting… really not worth the hassle.

8

Based on how those forum posts read, it sure sounds like it has to do with 1&1’s server setup and thus needs some adjustments to the site’s .htaccess file. I’m not sure what the server setup is, but you could try adding the following, if you haven’t already and if the sites are running PHP 7, which would follow the basic pattern. I would assume the x-mapp-php option would need to match the running PHP version.

AddType x-mapp-php7 .php

Given what you’re saying, @laurens1991, I would think the issue might be in their rewrite setups with however the base directory is configured.

Could either of you, @chris_jung as well, be able to work with 1&1’s support to get access to some of the server’s log files? If there is a 500 level error, I would think we should be getting at least something in the logs.

9

Hey folks,

I stumble over the same problem when uploading my grav website to an 1&1 / Ionos Account, but I’ve found a simple workaround. Just create a subfolder as root folder for your grav website and let the domain point to this subfolder. That solve the problem with the predefined 1&1 logs folder.

Best,
Christian

1 Like
10

Thanks for this smart solution. This should work with all webspace providers with limited access and predefined system folders in the root path. Great job! :slight_smile: