stoneyb

3.9.8.3 isn’t appearing yet, but I removed line 35 as you suggested, and everything works correctly now. Thanks!

That worked!

I noticed a few places in File Away where fileaway_utility::timezone();
is called, but there’s a return before
date_default_timezone_set($original_timezone);
is called, e.g. in class.fileaway_stats.php, line 118. That’s apparently not the cause of this problem, but it seems wrong anyway.

I tried disabling all my plugins, then reactivating File Away. The time was correct until I activated only File Away, then it was wrong.

I also checked all my themes for calls to date_default_timezone_set(), but there were none.

I set the timezone in my php.ini to ‘UTC’, which didn’t make any difference.

The evidence I see points to File Away as the culprit. I’m going to have to run this under a debugger to see what’s going on.

Unless the page is being cached. I clear my website cache when I update files.

This update worked just fine, although like the two prior ones I’ve updated to today, it produced an error message in the plugin’s box on the plugin page, that said: “Update Failed: Plugin update failed.”

The plugin files all appear to be correct, though. I don’t know what caused this. A DB update problem?

So far as I can tell, though, it works, and has the “allow symlinks” option now.

Thanks again!

Yes! It works with an absolute symlink but not a relative one (../files).

Thank you so much!

What is the problem just using realpath() directly? I assume that’s what you used to do. Some sort of security problem?

I’ll try the upcoming new version and let you know.

Oops! Too much multitasking. Sorry about that

I tried to update the plugin, but got an error “Plugin Update Failed”. Refreshing the page shows that 3.9.7.8 is installed though.

In any case neither the relative nor the absolute symlink worked.

I’m actually running PHP 7.1.22. Why do you think it’s < 5.5?

Should I try this new version?

Thanks for all your help!

The site is https, so files get DL’d that way, but there’s no encryption of the links themselves.

I’m puzzled by that too. From backups, I see that I had a symlink in wp before, but somehow it disappeared.

The one in a recent backup points to ../files, so if you changed something to disallow following “..” in a path, that would have broken it. I don’t know what happened to the symlink itself, though. Perhaps I was mistaken about it being missing.

Since an absolute path in the symlink didn’t work, did you also disable following symlinks altogether?

My root .htaccess does not rewrite all accesses to the wp directory, just the top level.

Redirect permanent /index.html /wp/

The innermost directory that I can’t edit is “wp”. The base dirs are all /home/username/dommainname/wp/

Changing the Root Directory to “WP Install Directory” does not change the Base Directories, or make them editable.

Yes, my Root Directory is set to “Site Root Directory”

Things are working now.

I was happy to see that I now could connect SSP with the UU_Services plugin’s “speakers” taxonomy using only a simple function in my child theme. Thank you!

My next task is to see if I can get all the podcasts that are entered via the UU_Services posts to show up in a particular feed. I hope that’s as easy.

I determined that even though WP Rocket had been deactivated, it still had a redirection in the .htaccess file that was fetching the feed from its cache, which was quite stale. Activating WP Rocket updated the cache, and now it’s working.

Nevermind ??