As long as we have a logging API that defaults to writing to the filesystem, there is going to be a requirement that Joomla be able to write log files *SOMEWHERE*. Where exactly doesn't matter (which is why we have the global config for it), it just has to be possible.

I'm actually mildly curious now. How many hosting platforms have their own public_html/logs directory that this conflicts with? Most decent hosts that I've seen puts that logs directory outside the webroot (meaning it doesn't affect Joomla at all).

All Plesk-powered hosts have the unwritable, system-owned "logs" restriction. This is a Plesk restriction since AT LEAST 12 years ago. Possibly more, I do remember we had this directory in our Plesk server back in 2003. Plesk is the second most popular commercial hosting control panel after cPanel.

For this reason: +1 from me.

I am also curious. I support a site that uses 1&1 (described as the host exhibiting problems) and have successfully maintained and updated a Joomla site from 2.x through 3.3.4 and wrote files directly with no errors returned.

Could this be something to do with setup/configuration? I would think that if 1 site was having trouble and it was how the host setup a specific folder it would impact multiple sites.

@jwaisner What is the log directory setting in your Global Configuration? If you used Akeeba Backup to transfer/restore the site at any point it would have automatically changed it to "log" (no trailing "s"). Or maybe you had done that yourself. Also, have you activated AWStats on your account? The "logs" folder, at least in Plesk-based hosts, is used by AWStats to provide statistics and metrics from its Apache access log analysis.

I'm fine with renaming it if it's a valid issue, which it seems to be, I'm really just curious why it's taken 3+ years for this to be raised as "Joomla has to change this now" and how widespread the use case the change addresses really is; that's all.

I wonder why we include it in the upgrade package. Can't we just exclude it from the package? We're not going to change anything in that folder and since it's an "optional" folder (as it can be configured) it doesn't make sense to hardcode it into the package.
This would solve the issue as well.

@Bakual you're a little late on that one, somewhere in these issues I pointed out some of the logic in the current system.

But to summarize again. If folder is in extension manifest, it HAS to be included in the package, always. Joomla is treated as a files extension which is why you can update Joomla with the Extension Manager. If you are going to change how anything is packaged, you have to change the manifest and you HAVE to test all upgrades to make sure we are not losing data (deleting existing logs or tmp folder, both of which may be in use). Because of the "Joomla is updated as an extension of Joomla" structure and the rules on extension manifests, there is not a simple "if package !== full" rule to be applied to the build script in this condition.

Ah sorry, missed that one about the manifest then.

Another idea would be to create the logs folder as part of installation process instead of having it in the manifest/package. Just trying to think of alternatives. Or do I miss something again?

@mbabker There is no demand "Joomla has to change this now" or rush for this - but it is a problem with a major webhost and has been for those 3+ years and during that time @nikosdion and I have just worked around it in our various code by using singular "log" instead of plural "logs" (e.g. in Kickstart extracted archives)

Is there a reason we cant move the default logs folder just into the tmp folder?

What path does Joomla write the directory to? Is it user configurable since obviously our defaults seem to cause conflicts with some software configurations or is it hardcoded? What happens if the directory can't be created (i.e. How well does JLog error trap for a condition when the log directory doesn't exist and can't be created)? Just a few things you need to address if you aren't going to explicitly include the directory in Git (and inherently packages).

Logs aren't a temporary thing. So if we did that users would have to be explicitly instructed on not deleting that internal directory if they are cleaning the tmp directory instead of just doing an rm rf ..

haha to me logs are the first thing I delete to free up space :) so are very temporary :-)

Joomla doesnt do a good job of keeping tmp clean anyway :)

Moving /logs to /log would mean we invalidate menu items with the "log" alias. It's not likely that anyone used this for his menu item but it still is a minor B/C break if we did that.
It would fix the issue for the hosts occupying that folder already, but it still doesn't solve the issue that the folder will be recreated on each update, even if you have configured it to another directory. So there is no way to get rid of it.
Moving it into /tmp/logs would not be in my favor either. Also the tmp folder is a configurable folder as well, and thus faces the same potential issue.

What path does Joomla write the directory to? Is it user configurable since obviously our defaults seem to cause conflicts with some software configurations or is it hardcoded? What happens if the directory can't be created (i.e. How well does JLog error trap for a condition when the log directory doesn't exist and can't be created)? Just a few things you need to address if you aren't going to explicitly include the directory in Git (and inherently packages).

I honestly don't know if we log anything during installation. If we do, it would already fail as of today on those hostings if I understand it right.
We could add the logs (and maybe even tmp) directory as prefilled fields in the first installation step. Or we could just use the "logs" folder as default and fall back to "log" as a second try, making it "autoguessing" a valid path.
If the directory can not be created, the installation would fail with an error message. I guess on hosts with that setup the installation already is tricky as of today because you can't even upload the full package.

It's just an idea how we could solve this in a way that doesn't need to rename the folder. And are we sure there are no hosts which have a "log" folder there?

We can easily implement auto-detection during installation. During regular runtime operation (see: back-end) we should print a message if the configured log directory is unwriteable and offer an action button that does auto-detection of a writeable directory. If one is not available give the user instructions on creating one. This requires 1. a minor change in the installation script 2. a system plugin to test the writeable status of the log folder in the back-end (the results would be cached in the session) 3. a new task in com_config for the auto-detection of a writeable directory or displaying the manual instructions.

I think that it needs a PLT discussion as it's a minor new feature. If you're interested I guess I can provide the code.

Closed as we have a PR #10301