Bob's SiteCheck 1.3.0

Support Extras
1

Hi Bob, today I tried your SiteCheck with MODX 3 and it works as far as I can say. Thanks!
Herewith I would like to report about it and some small issues.

  1. I fixed a sql collation on my new MODX 3 installations:
    modx_actions_fields, had the sql collation utf8mb3_general_ci instead of utf8mb4_general_ci

Q1: This seems to be the case with all MODX 3 installations and maybe it is desired?

  1. Checking Transport Packages shows these errors:
    Checking Package: resizer-1.0.1-pl -> Source: resizer-1.0.1-pl.transport.zip Package has no transport file
    Checking Package: tinymcerte-2.0.9-pl -> Invalid package_name

Q2: I guess it appears because the resizer is a beta, but I do not understand what is invalid about the Tiny RTE package?

  1. open_basedir in Error Log generated by SiteCheck:
    (ERROR @ /var/www/MyDomain.tld/httpdocs/modx/core/components/sitecheck/model/sitecheck/pathcheck.class.php : 659) PHP warning: file_exists(): open_basedir restriction in effect. File(/var/www/MyDomain.tld/httpdocs/modx/core/components/sitecheck/model/sitecheck/pathcheck.class.php/config.core.php) is not within the allowed path(s): (/var/www/MyDomain.tld/:/tmp/)

Q3: What do I need to add in php.ini at the line open_basedir? This doesn’t work:
open_basedir = /var/www/MyDomain.tld/:/tmp/:/var/lib/php/sessions/

If I leave it blank, the error does not appear. Is that important? It seems to work even with this error.

  1. Two more messages in Error Log generated by SiteCheck:
    (ERROR @ /var/www/MyDomain.tld/httpdocs/modx/config.core.php : 7) PHP warning: Constant MODX_CORE_PATH already defined
    (ERROR @ /var/www/MyDomain.tld/httpdocs/modx/config.core.php : 8) PHP warning: Constant MODX_CONFIG_KEY already defined

Q4: Maybe you can fix that in the next update?

my environment:

  • PHP: 8.1.11
  • mySQL: 8.0.30
  • MODX 3.0.2-pl
  • pdoTools 3.0.1-pl
  • sitecheck-1.3.0-pl
  • tinymcerte-2.0.9-pl
  • pthumb-2.3.3-pl
  • resizer-1.0.2-beta

btw: Package Readme SiteCheck → “Bugs and Feature Requests https://github.com/BobRay/SiteCheck” doesn’t exist.

2

Thanks for the report and for buying SiteCheck.

Does this files exist in core/packages?
resizer-1.0.1-pl

The filename may not match the signature of the package.

Looking at MODX Extras | Lean, Flexible, Community-Made Extensions for TinyMCE, I think the package name, or signature, may not match the filename.

I could not find an mb3 reference in my MODX 3 installs. It might be a reaction to a setting in your database, especially if you’re running MariaDB Enterprise.

At one time, mb3 was faster, but no longer. See this.

I don’t think any of these are problems in the SiteCheck code, but I could be wrong.

3

Hello Bob, thanks for reply and your tools.

on point 1:
Also in a new MODX 3.0.0-pl installation (now 3.0.2-pl) that I installed locally for testing, the modx_actions_fields had a mb3 reference instead of mb4. Weird, my collation default is utf8mb4_general_ci. No matter why, but your SiteCheck has found my fault :slight_smile:

btw: Locally I use MariaDB and on the live site MySQL.

on point 2:
No, the resizer-1.0.1-pl doesn’t exist, because it is a new installation and only the resizer-1.0.2-beta works with MODX 3. I checked the TinyMCE Rich Text Editor from MODX EXTRA (loaded and installed via manager), everything looks fine to me.

OK, it doesn’t seem important to me, because everything was installed properly and is working

on point 3:
I also think that this is not a fault of your tool. It has something to do with the settings of open_basedir.

on point 4:
I suspect that this message appears from SiteCheck? I get this on my live site and on my local test site.

4

On point 4, I think you’re correct. Each of the config.core.php are “included” and checked. There’s an @ sign on the include to suppress that error. I don’t see the error, and don’t know why you do, but the error is bound to occur, since I need to include all three of the files to check them. I could substitute my own error handler, but it seems like overkill.

5

The problem could be that in the schema, the “action” field has a type of nvarchar and not varchar.
nvarchar seems to be the National Character Set which probably is interpreted as utf8mb3.

1 Like
6

Hi Halftrainedharry, thanks for explanation!

As Bob mentioned with the link, even MySQL doesn’t see no longer use case for utf8mb3 anymore, therefore I leave it at utf8mb4.

The tool was developed to find errors or inconsistencies, and it really does :slight_smile: