Just tested it and I can confirm that it works. Thanks a lot! I’ll post a review on AMO right after this.

All right, thanks for looking into this — whatever the outcome.

I’m using Firefox 41.0 (in Ubuntu 14.04). Steps to reproduce:

1. Go to Firefox privacy settings, set ”Remember history” (allow FF to restart if needed)
2. Install jump to anchor
3. Verify it works (context menu has ”Jump to anchor”)
4. Go to Firefox privacy settings, set ”Never remember history” and allow FF to restart
5. Open context menu

What happens:
”Jump to anchor” is missing from the context menu.

I’m in a UTF-8 environment and a lot of my directories’ names have characters above ASCII in them. For many of those it’d be natural to assign bookmark names that also have characters beyond ASCII. For example, my ”Desktop” directory is localized as ~/Työpöytä, and I’d like to name that bookmark ”työpöytä”.

jani@saegusa:Työpöytä$ s työpöytä
bookmark name is not valid

This fails because bashmarks validates names using the regexp /[^A-Za-z0-9_]/. It’s simple enough to patch to account for the 6 additional characters in my Scandinavian locale, but bashmarks also derives an environment variable name from the bookmark name, and apparently Bash does not support UTF-8 for those:

jani@saegusa:~$ LC_MESSAGES=C export DIR_työpöytä=$HOME/Työpöytä/
bash: export: `DIR_työpöytä=/home/jani/Työpöytä/': not a valid identifier

There may be other obstacles as well, those are just the two I could find at a glance.

Obviously I can work around this by not using UTF-8 in bookmark names, but it needlessly increases the mental effort required to recall the names and also the chances of name collisions.

Upgraded to 8.1 today and the issue remains.

So I set up a Debian Wheezy VM just to test this, and was able to reproduce it straight away: did a clean install of 8.1 in /var/www/owncloud/ and set the data directory to /var/www/oc (whose owner I set to www-data:www-data). After installer was finished, selecting Admin from the Admin menu immediately causes ”File does not exist: /var/www/owncloud/data” to show up in error.log.

There was also this other error associated with it (copying here by hand instead because haven’t set up copy & paste in VM yet):

touch(): Unable to create file \\/var\\/www\\/owncloud\\/data\\/owncloud.log because No such file or directory at \\/var\\/www\\/owncloud\\/lib\\/private\\/log\\/owncloud.php#53

It would seem to hint the source of this being OC_Log_Owncloud::init (which is where the line it refers to belongs to AFAICT). For some reason this message about touch() failing does not show up on my actual installation’s logs (the one I pasted the logs from in the initial report above). It no longer seems to show up in the VM either after I raised logging level up to ”Errors and fatal issues”; not even after I lower it back down to ”Info, warnings, errors and fatal issues”; only the ”File does not exist: /var/www/owncloud/data” still keeps appearing. Perhaps the vanishing of that other message is also caused by the same problem with OC_Log_Owncloud::init.

@PeterDaveHello done, hopefully right this time! Thanks for guiding me through this (it’s my first pull request, in case you couldn’t tell).

Hi @PeterDaveHello, the issues you mentioned should now be fixed. (I’m making this comment in case you’re not receiving notifications about the fix commits and test automaton pass, but do tell if more fixes are needed.)

Hi,

I’m getting this entry in my server log when I open the latest post in single-post view:

Trying to get property of non-object in [...]/wp-content/themes/cover/inc/template-tags.php on line 61

It looks like the reference to $next->ID on said line is causing this; there’s no next post from the newest, obviously. There is a test for ! $next && ! $previous on line 51, but I’m guessing the block generating$next_img_array for next_post_link should also be wrapped with a separate test for the existence of$next, to suppress the error.

Okay, I disabled all apps and the issue remains: the log still gets a new ”not exist” entry when I select ”Admin”.

Ha, got it! It’s the act of selecting ”Admin” from the ”admin” dropdown menu (top right) that triggers it. Nothing else seems to do it (”Users” from the same menu for example doesn’t trigger it).

There’s now also this in the log:

File does not exist: /var/www/userhome/mummila/sites/mummila.kapsi.fi/secure-www/oc/assets/dist, referer: https://mummila.kapsi.fi/oc/index.php/apps/gallery/

But I’d wager it’s completely unrelated to the other ”not exist”, as I only activated asset-pipeline yesterday. Browser’s JS log says it’s missing assets/dist/jquery-migrate.min.map; it doesn’t say anything about the data directory that the server log complains about.

While poking around, I also noticed that for my non-admin OC user, selecting Pictures from the Apps menu brings up the Pictures view, but it fails to load any pictures. The loading spinner just keeps spinning forever. The admin user’s Pictures view does work, i.e. it actually loads the pictures too. I’m not sure if this is related to the log issue either, but thought I’d mention it anyway.

Any ideas on how I can narrow this down further?