Aaron

I think that issue has been solved.

Hey. Thanks for letting know about that. I moved the load_plugin_textdomain() function to the init() hook in version 2.36.2. Hopefully that fixes it.

Thank you for providing the log file. Hopefully I fixed this in version 2.35.23.

I see. When do you get that error exactly? Can you reproduce it with a specific URL?

Would you paste the debug file contents to https://pastebin.com/ and send me the link here? The debug file is under 404 Solution -> Options (tab) -> Advanced Settings Etc -> View (the debug file). You can copy the contents, paste it at pastebin.com, click “Create New Paste” at the bottom, and send me the URL from pastebin here. (Do not post the debug log file here as it’s too big.)

Aaron

Sorry for all the issues. Please let me know if it happens again with the version (2.35.22).

thanks

I’ve tried to fix this in version 2.35.21.

Let me know how it goes.

thanks

Hello,
When did the problem first appear?
What version are you using?
Please try uninstalling it and reinstalling it.

thanks

Hey,

Thanks for letting me know about the continued issues. The most recent one might be fixed with version 2.35.17.

Let me know if you get another chance to try it.

thanks

Aaron

Thanks. I appreciate it.

Hey,

This might be fixed in version 2.35.16. Let me know if you get another chance to try it.

thanks

Aaron

Hey crzyhrse,

I’m sorry it’s not working. The error you’ve pasted this time is different than the first one.

As far as I can tell it seems to be a case issue with table names. My guess is that your mysql setting is lower_case_table_names=0.

Any chance you can change the setting in my.cnf to

[mysqld]
lower_case_table_names=1

?

I’m having trouble testing it my system because my file system is case-insensitive and MySQL relies on the file system’s behavior for handling case sensitivity. So I can’t just set my setting to lower_case_table_names=0 to test it because I get an error message and the server doesn’t even start.

If changing that setting isn’t a possibility for you, just let me know and I’ll see what I can do, but basically it will be a huge pain for me because I guess I have to create a new partition with a different file system and then move the mysql data files to that partition in order to get the lower_case_table_names=0 setting to work so that I can test the plugin again with that setup. It will take some time I guess, as I’ve never done that before.

regards

Hey atlet,

Thanks for letting me know. I made some changes in version 2.35.15 so let me know if that fixes it.

If not then:
* Are you using mysql?
* Please delete the debug log, turn on debug logging, reproduce the error, view the debug log, paste the entire contents of the debug log to https://pastebin.com/, click the “create new paste” at the bottom, and send me the link to the paste at pastebin here in the forum. (Do not paste the log file here as it is too big and the admins will come in and delete the message). The debug log links for deleting and turning it on are on the 404 Solutions settings page under “Advanced Settings (Etc)” all the way at the bottom, or you can just search the page for “Debug logging” to find it.

thanks

Sorry, I forgot to answer your question. The series of letters and numbers after the IP are a one-way hash of the rest of the actual IP address so that the real IP address is hidden to comply with the GDPR. A one-way hash is used so that the same IP will always result in the same series of letters and numbers for the same IP, so that in the logs you can see if the same IP did multiple actions.

On the settings page under “Advanced Settings (Etc)” there’s an option to log raw IPs naned “Log raw IPs”.

Logging raw IP addresses may not meet the EU General Data Protection Regulation (GDPR) guidelines

An explanation from Gemini:

The GDPR does not explicitly prohibit logging raw IP addresses. However, it does require that personal data be processed lawfully, fairly, and transparently. This means that website owners must have a legitimate reason for processing IP addresses and must obtain appropriate consent from users.

If a website owner is processing IP addresses for a purpose that is not considered legitimate under the GDPR, this could be considered a violation. For example, if a website owner is logging raw IP addresses for marketing purposes without obtaining explicit consent, this could be a violation.

Here are some factors to consider when determining whether logging raw IP addresses is lawful under the GDPR:

• Purpose: What is the purpose of logging IP addresses? Is it necessary for the website’s operation?
• Consent: Has the website owner obtained appropriate consent from users to process their IP addresses?
• Anonymization: Can the IP addresses be anonymized to protect user privacy?
• Retention: How long are IP addresses retained? Are they deleted after a reasonable period of time?

Fixed in 2.35.13