After upgrading to TYPO3 9, some of the tx_news_domain_model_news path_segment fields were empty, so I marked Upgrade Wizard
"Updates slug field "path_segment" of EXT:news records" of news extension" as undone and tried to execute it. This throws an exception. Makes no difference if executed via backend or on command line, though the command line shows a success message before the error::
typo3-cli upgrade:run newsSlug
Output:
In UpgradeWizardsService.php line 466:
No valid wizard identifier given
in /var/www/domain/htdocs/typo3_src-9.5.5/typo3/sysext/install/Classes/Service/UpgradeWizardsService.php line 466
*/
protected function assertIdentifierIsValid(string $identifier): void
{
if ($identifier === '' || (!isset($GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['ext/install']['update'][$identifier]) && !is_subclass_of($identifier, RowUpdaterInterface::class))) {
throw new \RuntimeException('No valid wizard identifier given', 1502721731);
}
}
}
Current TYPO3 version 9.5.5.
There are changelog entries:
Deprecation: #86366 - Methods in AbstractUpdate
Feature: #86076 - New API for UpgradeWizards
There is a new Interface for upgrade wizard, but as far as I understand it, the "old" update wizards with AbstractUpdate should still work in 9.x.
Is this a bug? I've got the original problem solved, because the update wizard did successfully convert the entries (see original question).
I'd just like to have clarification for implementation of update wizards in TYPO3 9.
Yes this was a bug in the news extension and fixed in master. Be aware that the implementation of update wizards changed in 9 a bit, therefore also this bug occurred.
Related
After creating my own Extension with the ExtensionBuilder-Package and activating it, I created a repository for the data and set the Storage-PID in the Template-Constants.
Then I created a new page containing the extension (with default values) and on viewing the page the following error appears and the page does not show:
Core: Exception handler (WEB): Uncaught TYPO3 Exception: Class '0;' not found | Error thrown in file /var/www/html/typo3Insy/public/typo3/sysext/core/Classes/Utility/GeneralUtility.php
For the setup I used the TYPO3 version 9.5.23 and have not migrated from a previous one.
Thanks to #Jack70 I found out, that an autoloader needs to be supplied for my own extension in the composer.json-File of the TYPO3-installation itself.
From the composer.json-File of the created extension itself, you can extract the vendor name and the site package. Make sure the case matches when supplying it to the autoloader-section:
"autoload": {
"psr-4": {
"MyVendor\\MySitePackage\\": "pathToTheClassesDirectoryOfYourExtension"
}
}
After that you can simply run composer dump-autoload and this error will be fixed (without restarting the webserver).
I found out about this here: https://wiki.typo3.org/Exception/CMS/1289386765
Here is my error. Comes with a stacktrace but guessing this will be good enough. This project worked fine before the patches.
[2020-07-28T10:20:45,262] WARN services.ProjectManagerService - Discovered filesystem project RossNapOISOperations, importing...
[2020-07-28T10:20:45,824] ERROR boot.SpringApplication - Application run failed
grails.validation.ValidationException: Validation Error(s) occurred during save():
Field error in object 'rundeck.Project' on field 'description': rejected value [Build/Deploy/Maintenance on ROSS, NAP, and OIS Projects]; codes [rundeck.Project.description.matches.error.rundeck.Project.description,rundeck.Project.description.matches.error.description,rundeck.Project.description.matches.error.java.lang.String,rundeck.Project.description.matches.error,project.description.matches.error.rundeck.Project.description,project.description.matches.error.description,project.description.matches.error.java.lang.String,project.description.matches.error,rundeck.Project.description.matches.invalid.rundeck.Project.description,rundeck.Project.description.matches.invalid.description,rundeck.Project.description.matches.invalid.java.lang.String,rundeck.Project.description.matches.invalid,project.description.matches.invalid.rundeck.Project.description,project.description.matches.invalid.description,project.description.matches.invalid.java.lang.String,project.description.matches.invalid,matches.invalid.rundeck.Project.description,matches.invalid.description,matches.invalid.java.lang.String,matches.invalid]; arguments [description,class rundeck.Project,Build/Deploy/Maintenance on ROSS, NAP, and OIS Projects,^[a-zA-Z0-9\p{L}\p{M}\s.,()_-]+$]; default message [Property [{0}] of class [{1}] with value [{2}] does not match the required pattern [{3}]]
That's related to how Rundeck 3.3.X interprets the project description after an instance upgrade, a good way to solve it is back to rundeck 3.2.X, edit the projects descriptions without "special characters" and update to Rundeck 3.3.1 again. You can add your issue to this GitHub thread.
Core: Exception handler (WEB): Uncaught TYPO3 Exception: Cannot use object of type __PHP_Incomplete_Class as array | Error thrown in file typo3/sysext/backend/Classes/Controller/Page/TreeController.php in line 189
This happened after a core update to TYPO3 - 9.5.17
https://forge.typo3.org/issues/91407
The following thanks to Michael Hitzler.
As far as I can see there is already a solution within the install tool in class BackendUserConfigurationUpdate.
This seems to address exactly the issue.
Not quite sure in which version the additional migration task has been added, but it helps you solving the issue system wide.
Just got to module Admin Tools -> Update and select Update Wizard.
There you should see a new, not yet executed migragtion task:
Update backend user configuration array
The backend user "uc" array, which is persisted in the db, now only allows for arrays inside its structure instead of stdClass objects. Update the uc structure for all backend users.
Execute this migration task and your BE users will be updated and have a sane uc configuration in the end.
Problem solved and page tree can be loaeded again.
./typo3cms upgrade:wizard backendUsersConfiguration
Should solve the issue.
i updated a project from TYPO3 7.6 to ^8 by following the official guide. latest steps were the composer update. i removed extensions/packages not compatible with ^8 and updated the ones available for ^8. im able to reach the install tool, the TYPO3 admin backend and the frontend (with errors).
so i ended up at the step were i should use the upgrade wizards provided by the install tool. i completed a few wizards without any issues but then faces a pretty one - first i tried to run DatabaseRowsUpdateWizard within the install tool but that failed with a memory error - i tried the cli approach with
php -d memory_limit=-1 vendor/bin/typo3cms upgrade:wizard DatabaseRowsUpdateWizard
the processing worked but it ended up with following error:
[ Helhum\Typo3Console\Mvc\Cli\FailedSubProcessCommandException ]
#1485130941: Executing command "upgrade:subprocess" failed (exit code: "1")
thrown in file vendor/helhum/typo3-console/Classes/Install/Upgrade/UpgradeHandling.php
in line 284
the command initially failed is:
'/usr/bin/php7.2' 'vendor/bin/typo3cms' 'upgrade:subprocess' '--command' 'executeWizard' '--arguments' 'a:3:{i:0;s:24:"DatabaseRowsUpdateWizard";i:1;a:0:{}i:2;b:0;}'
and here is the subprocess exception:
[ Sub-process exception: TYPO3\CMS\Core\Resource\Exception\InvalidPathException ]
#1320286857: File ../disclaimer_de.html is not valid (".." and "//" is not allowed in path).
thrown in file typo3/sysext/core/Classes/Resource/Driver/AbstractHierarchicalFilesystemDriver.php
in line 71
im pretty much lost and dont know were to start to get this fixed - help is much appreciated
Issues like these usually stem from broken URLs in RTE fields as can be seen in the error output:
File ../disclaimer_de.html is not valid (".." and "//" is not allowed in path)
In this case you should manually prepare the database and run SQL statements which replace the broken/obsolete ../ prefix from all affected records. An example query:
UPDATE tt_content
SET bodytext = REPLACE(bodytext, 'href="../', 'href="')
WHERE bodytext LIKE '%href="../';
Notice that this query is very basic and can destroy your data, so make sure you run some SELECT statements first to make sure nothing breaks. Also keep a backup of your database at hand.
Sometime, custom or TER extension also have RTE such as tt_news where you might come across same issue. To fix that, you just need to run the same query with the according table.
In an existing Grails 3.1.15 application, recently upgraded to Hibernate 5.1, an odd issue with afterInsert (or other) hooks started to appear. After some hours of testing, I could track this down to Hibernate 5.1 + PostgreSQL combination - issue is not reproducible with H2. To reproduce, create a simple application consisting of 2 domain objects - an Audit trail and a User, as shown here:
class Audit {
Date dateCreated
String auditData
}
class User {
String name
String email
def afterInsert() {
new Audit(auditData: "User created: $this").save()
}
}
The code above works OK with Hibernate 4, however, if the application is upgraded to Hibernate5 plugin + Hibernate 5.1.x (tested with 5.1.0.Final and 5.1.5.Final) the above scenario will always lead to a ConcurrentModificationException when you attempt to save a new User instance. You can just use a scaffold controller to reproduce. Note this only happens with PostgreSQL as the data source - with H2 it would still work OK.
Now, according to GORM Docs (see chapter 8.1.3) one should use a new session when attempting to save other objects in beforeUpdate or afterInsert hooks anyway:
def afterInsert() {
Audit.withNewSession() {
new Audit(auditData: "User created: $this").save()
/* no exception logged, but Audit instance not preserved */
}
}
But this wouldn't really resolve the issue with PSQL. The exception is gone, the User instance is persisted, but the Audit instance is not saved. Again, this code would work OK with H2. To really avoid the issue with PSQL, you would have to manually flush the session in afterInsert:
def afterInsert() {
Audit.withNewSession() { session ->
new Audit(auditData: "User created: $this").save()
session.flush()
/* finally no exceptions, both User and Audit saved */
}
}
Question: is this a bug, or is this expected? I find it a bit suspicious that the manual flush is required in order for the Audit instance to be persisted - and even more so when I see it works without a flush with H2 and only seems to affect PostgreSQL. But I couldn't really find any reports - any pointers are appreciated!
For the sake of completeness, I tested with the following JDBC driver versions for PostgreSQL:
runtime 'org.postgresql:postgresql:9.3-1101-jdbc41'
runtime 'org.postgresql:postgresql:9.4.1208.jre7'
runtime 'org.postgresql:postgresql:42.0.0'
And for the upgrade to Hibernate 5.1, the following dependencies were used:
classpath "org.grails.plugins:hibernate5:5.0.13"
...
compile "org.grails.plugins:hibernate5:5.0.13"
compile "org.hibernate:hibernate-core:5.1.5.Final"
compile "org.hibernate:hibernate-ehcache:5.1.5.Final"