The simpler media website CMS
This issue occurs on all themes (including untouched default zenpage theme). I can enable the favoritesHandler plugin and the site will still work, BUT ONLY if NOT logged in (IE, in an incognito window). AS SOON AS one logs in, whether as the admin or as a less-powerful user, the site throws a HTTP ERROR 500 on the front end only. The back end appears to work just fine at all times. Disabling the favoritesHandler plugin instantly solves the problem (but then, no favorites). Host is DreamHost. I set the PHP to 7.4 before uploading the site (DreamHost default is 8.2). I keep getting two back-to-back errors in my log, which I have copied below. Any help would be greatly appreciated:
{475542:Sun, 23 Oct 2022 14:51:07 GMT}
WARNING: mysqli::query(): (HY000/3685): Illegal argument to a regular expression. in /home/(mysite)/zp-core/functions-db-MySQLi.php on line 84
mysqli->query called from query (functions-db-MySQLi.php [84])
from query_full_array (functions-db-MySQLi.php [130])
from favorites->__construct (class-favorites.php [28])
from require_once (favoritesHandler.php [312])
from include (index.php [26])
from index.php [56]
{475542:Sun, 23 Oct 2022 14:51:07 GMT}
USER ERROR: MySQLi Error: ( SELECT aux
FROM [prefix]plugin_storage
WHERE type
="favorites" AND aux
REGEXP '[[::]]' ) failed. MySQLi returned the error Illegal argument to a regular expression. in /home/(mysite)/zp-core/functions-db-MySQLi.php on line 95
trigger_error called from query (functions-db-MySQLi.php [95])
from query_full_array (functions-db-MySQLi.php [130])
from favorites->__construct (class-favorites.php [28])
from require_once (favoritesHandler.php [312])
from include (index.php [26])
from index.php [56]
TopZenphoto version
Comments
We will try to look as at least I have not see this issue before.
The actual call with the construttor of class is this
That is a regular expression. Perhaps
$user
is missing for you for some reason. Does your user name contain any special chars like accents or something perhaps?My username is just my name (David). No special characters. Last night, before I started from scratch to fix the tag issue, when I was having the same issue with the favorites plugin, I'm pretty sure the error logs showed REGEXP '[[:<:]]David[[:>:]]' with my name in it (something similar to that, from memory, whereas now it's just REGEXP '[[::]]'.
Is there something I can check for you to assist?
So with uppercase? What encoding are you using in the db? Just asking in case there is some case sensitive vs case insensitive going on (it is preferred to use case insensitive encodings).
If you can take a look at teh database table plugin_storage and search for favoriteshandler entries and what is stored there.
Did my best to check things for you. Via myphpadmin for the database.
For the "information_schema" for the databases, under COLLATION_CHARACTER_SET_APPLICABILITY I clicked the "Structure" tab and I see:
COLLATION_NAME and CHARACTER_SET_NAME are both type: varchar(64) and Collation: utf8_general_ci
Then looking at the list of many possible Charsets for the database and scrolling down to utf8_general_ci, I see:
Unicode, case-insensitive (this Charset is also shown to be the default).
I found the table "plugin_storage" and filtered rows by searching for "favorites" and there was one line. I clicked "Copy" so I could see it, I found a list of one favorite. Apparently, in my original post I forgot to mention that on the fresh install, when I turned on the favoritesHandler plugin, the site did not throw the error until I (who was logged in as the admin) clicked "add to favorite" for a picture to test it. As soon as I clicked "add to favorite", the 500 error appeared, and did so every time I turned on the plugin when logged into the site on the front end (thus it does not throw the error if I open an incognito tab and am thus not logged in, until I log in, even with someone else's username than my own, for which there would be no favorites saved yet). My apologies for not having noted this earlier... it happened so fast, and then I tried to trouble shoot for a while before posting.
Because of this one-time clicking of an add to favorites before the 500 error, there are four sections of data:
for: id int unsigned, there is nothing (Value box is blank)
for :type varchar(32) the value is "favorites"
for aux varchar(255), there is "David"
for data longtext, there is my entry:
a:2:{s:4:"type";s:6:"images";s:2:"id";s:55:"Christmases/Christmas-1975-79/DavidKidChristmasTree.jpg";}
If you need anything else, please let me know, and thank you so much for your help. Sorry again I didn't mention that the site didn't throw the 500 error until the first time I clicked "Add to favorite" before. I didn't even think the favorite was saved, as the error was instant, if I remember correctly.
Thanks. you also can get coaltion etc info via the database info utility on the overview page. That all looks okay to me generally. I have no idea about the issue right now.
What mysql (or mariadb) version are you using? This regex is not that special unless probably for really stone age mysql verions but in case…
Under General Settings, for Server connection collation: there is a drop down where it looks like I could change it to a bunch of languages, but it is defaulted to utf8mb4_unicode_ci.
Also, on the overview page
Server type: MySQL
Server version: 8.0.28-0ubuntu0.20.04.3 - (Ubuntu)
Protocol version: 10
User: ~~~~
Server charset: UTF-8 Unicode (utf8).
Separately, for my NAS, where the plugin works without issue, I have same server connection collation (utf8mb4_unicode_ci), but a MariaDB:
Server: MariaDB 10 (Localhost via UNIX socket)
Server type: MariaDB
Server connection: SSL is not being used Documentation
Server version: 10.3.32-MariaDB - Source distribution
Protocol version: 10
User: root@localhost
Server charset: UTF-8 Unicode (utf8)
Both versions look okay to me. And don't change encoding via these dropdowns, you may cause troubles any utf8 is good. While being not really new we are starting to ussport utf8mb4 finally in 1.6 but the implementation is not fully finished yet. But that is surely not the reason for your issue which you already go in 1.5.9.
I still have no idea about the issue right now sadly…
Thank you for your efforts. If you think of anything else, let me know. Overall, I'm quite happy with Zenphoto. I just thought favorites would be neat for my family members who may want to save favorite photos relevant to them from the large group (over 2000 pictures scanned from my parents photo albums). If this feature needs to wait until 1.6, then I can live with that; but if you're like me, you do like to sort out all possible issues regardless (I can be a bit manic about such things). I appreciate all your efforts.
We of course want that to work as intended. But we need to reproduce it and so far sadly my colleague can't either. But in any case the fix will be in 1.6 only.
Intended release target for 1.6 is mid november.
Sorry I didn't see this request until today. I took another domain on DreamHost (btw, DreamHost is forcing a PHP upgrade in December or there will be a forced monthly support fee for those still on anything below PHP8), set the PHP to the recommended PHP (PHP 8.0 FastCGI), and uploaded ZenPhoto 1.6a, and ran setup. Uploaded a folder, sub folder, and two pictures. Everything seemed to work. Turned on the favoritesHandler plugin and went to one of my two photos. As soon as I clicked "Add Favorite" the site threw the PHP error:
([mydomain].com is currently unable to handle this request.
HTTP ERROR 500
I re-ran setup to show you what is there that might be relevant:
PHP tidy support [is not present]
Warning!
tidy support is not critical but strongely recommended for properly truncating text containing HTML markup.
Warning!
Perhaps there was a problem with the upload. This may not be critical at all as perhaps just the file times may be off compared to other files. You should check the following files:
zp-core/zp-extensions/openstreetmap/images/loader.gif
zp-core/zp-extensions/openstreetmap/images/marker-icon-grey-2x.png
zp-core/zp-extensions/openstreetmap/images/marker-icon-grey.png
zp-core/zp-extensions/openstreetmap/images/toggle.png
zp-core/zp-extensions/openstreetmap/images/toggle.svg
zp-core/zp-extensions/uploader_jQuery/wdio/conf/edge.js
zp-core/zp-extensions/uploader_jQuery/wdio/conf/internet-explorer.js
zp-core/zp-extensions/uploader_jQuery/wdio/conf/safari.js
There was a core file that it said shouldn't be there the first time I ran setup, but I deleted that as recommended before thinking to write it down. My memory of what it is is shorter than I want, so I'd have to start over to see. I'm on limited bandwidth tethering to my phone to do this stuff, but will re-upload if you want me to.
Turning off the plugin does immediately allow the front-end to work again.
Those warnings are not critical as their comment tells. We still have no idea but will try to find out…
The file you delete was probably one starting with a dot, an invisible file like Windows or macOS often create for folder settings. That's probably not an issue.
But since it is an unfinished release we might have fogotten to update the internal package catalogue on some changes. But even then it would not be critical.