This module 1.2, Silverstripe 3.7, PHP 7.4 and Postgres 10 - [Deprecated] Invalid characters passed for attempted conversion, these have been ignored

[muppsy007]

We've upgraded a 3.2 site to 3.7 to take advantage of PHP 7.4. Postgres version is 10.15 running on RHEL 8.

On dev/build, we see the following notices. Always identical, the only things that change are the argument to extractTriggerColumns() method, the object argument for indexList() (File below), and the second argument of the requireIndex() method (ParentID below)

[Deprecated] Invalid characters passed for attempted conversion, these have been ignored
GET /dev/build?devbuildtoken=blah
Line 791 in /vagrant/web/postgresql/code/PostgreSQLSchemaManager.php

Trace

- hexdec(\x)
  PostgreSQLSchemaManager.php:791
- PostgreSQLSchemaManager->extractTriggerColumns(ts_2acf7ae38066c7cee5ae8cf8a617285e)
  PostgreSQLSchemaManager.php:841
- PostgreSQLSchemaManager->indexList(File)
  DBSchemaManager.php:403
- DBSchemaManager->requireIndex(File,ParentID,Array)
  DBSchemaManager.php:356
- DBSchemaManager->requireTable(File,Array,Array,1,Array,)
  DB.php:530
- DB::require_table(File,Array,Array,1,Array,)
  DataObject.php:3533
- DataObject->requireTable()
  DatabaseAdmin.php:244
- DatabaseAdmin->{closure}()
  DBSchemaManager.php:126
- DBSchemaManager->schemaUpdate(Closure)
  DatabaseAdmin.php:246
- DatabaseAdmin->doBuild(,1)
  DatabaseAdmin.php:103
- DatabaseAdmin->build()
  DatabaseAdmin.php:80
- DatabaseAdmin->index(SS_HTTPRequest)
  RequestHandler.php:296
- RequestHandler->handleAction(SS_HTTPRequest,index)
  Controller.php:192
- Controller->handleAction(SS_HTTPRequest,index)
  RequestHandler.php:208
- RequestHandler->handleRequest(SS_HTTPRequest,DataModel)
  Controller.php:151
- Controller->handleRequest(SS_HTTPRequest,DataModel)
  DevBuildController.php:25
- DevBuildController->build(SS_HTTPRequest)
  RequestHandler.php:296
- RequestHandler->handleAction(SS_HTTPRequest,build)
  Controller.php:192
- Controller->handleAction(SS_HTTPRequest,build)
  RequestHandler.php:208
- RequestHandler->handleRequest(SS_HTTPRequest,DataModel)
  Controller.php:151
- Controller->handleRequest(SS_HTTPRequest,DataModel)
  RequestHandler.php:230
- RequestHandler->handleRequest(SS_HTTPRequest,DataModel)
  Controller.php:151
- Controller->handleRequest(SS_HTTPRequest,DataModel)
  Director.php:383
- Director::handleRequest(SS_HTTPRequest,Session,DataModel)
  Director.php:147
- Director::direct(/dev/build,DataModel)
  main.php:206

This portion of code is the originator of the notice. Going through what comes before it, there's a query to get the tgargs field from pg_catalog.pg_trigger, which is a bytea field. Then a str_split is used to break the bytea contents into 2 character chunks. It seems that some of those chunks end up invalid for use in hexdec(). (\x). Hence the deprecation notice. All told, our dev/build gives us 30 of these notices. And they ALL come from core SS tables File, SiteTree, SiteTree_versions and SiteTree_Live. Never from any custom models.

There is a comment above this specific hex-handling block that alludes to it even being required being a mystery. Is that still the case? Is there any indication on what the offending PGSQL config might be.

// Option 2: hex-encoded (not sure why this happens, depends on PGSQL config)

Although this is just a notice, it seems impossible to disable Deprecation notices on SS3.x as framework/core/Core.php overrides any php.ini settings. But more importantly, it's not really apparent if these notices are heralds of a yet unseen problem.

Switching to PHP 7.3 hides the notices, but the problem is likely still happening there, just not reported. So I guess this issue is either Silverstripe 3.7, Postgres config, or something in this module.

Any thoughts or experience?

[maxime-rainville]

Silverstripe 3 is in limited support. In all honesty, making sure it works without warnings with PostgreSQL and PHP7.4 is pretty far down in our priority list.

If you want to make a PR to address this specific issue, I'd be happy to review it and do a patch release of the PostgreSQL module to ship the fix.

[muppsy007]

That actually runs counter to silverstripe core development, which is to support PHP 7.4. Even on the 3.x branch. It also ignores part of my question about this not only being a warning, but a potential risk to the health of this module at all. This warning is not just a warning. It means that whatever data is being fed to the function that triggers the warning ends up being ignored.

I'm asking for any background info on this so I can actually begin to find a fix in the first place. Hence the discussion about existing comments in code. At some point developers of this module were not sure why something happened the way it did, so I wouldn't be expected to and just do a PR. I specifically asked if there was any clarity on this since the comment was made.

It's a historical/technical risk discussion first and foremost.