TYPO3 Core

Damir Andrašević wrote:

By the error dump, it seems to me as if temporary page uid is not converted to the real uid, the query looks like one that is created with the query beginning on the line 634 of

[...]

but that is as far as I've gotten for now (given my still low knowledge of TYPO3 core files). And not really sure if I'm looking at the right direction as it seems it's only connected to the specific menus.

Scratch this and sorry for the mislead. I was on the wrong track there, used the right grep now and with a little help of debug utility found the right one...

The main culprit is in the file:

./typo3/sysext/backend/Classes/Controller/EditDocumentController.php

specifically, the lines starting on line number 1752:

      if ($id) {
            $queryBuilder->getRestrictions()
                ->removeAll()
                ->add(GeneralUtility::makeInstance(DeletedRestriction::class))
                ->add(GeneralUtility::makeInstance(BackendWorkspaceRestriction::class));

            if (!$this->getBackendUser()->isAdmin()) {
                $queryBuilder->getRestrictions()->add(GeneralUtility::makeInstance(HiddenRestriction::class));
            }

Changing this to (for new page it will return null and thus not enter/execute the loop/query):

      if ($tce->substNEWwithIDs[$id]) {
...

makes the create new page work like intended.

Not sure if this solution is the best practice, so feel free to make any correction(s) necessary.

Georg Ringer wrote:

Thanks for creating the issue!

I don't yet understand how the ElementInformationController can be called with a not yet persited page. Can you give me some hints how to reproduce this?

Thanks!

Hi Georg!

Wow, it's been a while for this issue, almost forgot about it and in the meantime run over my former laptop setup where I had this. I'll check this issue tomorrow with a migration of one of my v8 installations and report here with detailed error dump and how to reacreate it (if it can be done, v9 has been updated quite some times now).

I'll report back soon!

BR,
Damir

Hi,

just to add an update, I've not yet replicated the issue as I'm having problems with basic TYPO3 installation on postgres right now (TYPO3 v8.7.31 and Postgres 10/11) as it seems there is some kind of Doctrine/DBAL issue.

While trying to access "Upgrade Wizard" inside TYPO3 admin, following error will be thrown:

Core: Exception handler (WEB): Uncaught TYPO3 Exception: An exception occurred while executing 'SELECT min_value, increment_by FROM "be_groups_uid_seq"':
SQLSTATE[42703]: Undefined column: 7 ERROR: column "min_value" does not exist LINE 1:
SELECT min_value, increment_by FROM "be_groups_uid_seq" ^ | Doctrine\DBAL\Exception\InvalidFieldNameException thrown in file 
C:\dev\Apache24\htdocs\typo3.test.local\vendor\doctrine\dbal\lib\Doctrine\DBAL\Driver\AbstractPostgreSQLDriver.php in line 72.
Requested URL: http://typo3.test.local/typo3/install.php?&install[action]=upgradeWizard&install[controller]=tool&install[context]=backend

It seems to have some relationship with https://github.com/doctrine/dbal/issues/2868

I tried to circumvent the issue by editing doctrine core files as suggested in the issue, but it just fails somewhere later (as that doctrine hack is not the real issue of the problem, so partially expected). I'll try to analayze this a little bit more, I don't know if someone already encountered this problem...

Version on which I originally produced this issue was TYPO v8.7.19 and Postgres 9.16.15 so it could be that Postgres v10/11 are not covered so well. I'll check it out and reply my findings.

Edit. Is seems that doctrine/dbal is not the latest release in TYPO v8 and v9? And as the v8 is freezed I suppose it won't be. But this issue arises in v9 also as far as I see
Edit2. So I fetched the DBAL lib from v10 and put it in v8 and now this issue in v8 is gone. Nothing else seems to be broken, yet :)

Long story short, I cannot reproduce the issue any more, at least not on upgrade from TYPO3 v8.7.31 to v9.5.14 with Postgres v11 and v10, PHP 7.2 and 7.3. Migration goes more or less ok, and pages can be created without problem.
It is possible that this was just a issue with the v9 I was using at the time of creating the bug.

The problem that I encountered now with v8 and v9 while working with Postgres version >10 is as mentioned the old dbal library which is resolved by pulling the latest dbal libraray (one from TYPO3 v10.3.0).

After that "fix" only error that is being generated in database comapare tool is:

 select/deselect all
 ALTER TABLE "sys_file_collection" ALTER "l10n_diffsource" TYPE BYTEA 
Current value: l10n_diffsource TEXT DEFAULT NULL
 ALTER TABLE "sys_file_collection" ALTER "l10n_diffsource" DROP DEFAULT 
Current value: l10n_diffsource TEXT DEFAULT NULL
 ALTER TABLE "sys_collection" ALTER "l10n_diffsource" TYPE BYTEA 
Current value: l10n_diffsource TEXT DEFAULT NULL
 ALTER TABLE "sys_collection" ALTER "l10n_diffsource" DROP DEFAULT 
Current value: l10n_diffsource TEXT DEFAULT NULL

and in migration while trying to execute upgrade wizard's task "Introduce URL parts ("slugs") to all existing page" will fail with:

(1/1) PDOException
You cannot serialize or unserialize PDOStatement instances

in C:\dev\Apache24\htdocs\typo3.test.local\typo3\sysext\core\Classes\Cache\Frontend\VariableFrontend.php line 59
            ];
            GeneralUtility::callUserFunction($_funcRef, $params, $this);
        }
        if (!$this->backend instanceof TransientBackendInterface) {
            $variable = serialize($variable);
        }
        $this->backend->set($entryIdentifier, $variable, $tags, $lifetime);
    }
...

As far as I can see, this bug can be closed, I'll look up if there is ongoing bug trackers for the issues that I mentioned with dbal and Postgres.