You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
we did some testing on our installation, and if i run the update script: php bin/console ngscheduledvisibility:update --no-interaction
we get the following warning which produces an error log item:
[2024-06-27T11:58:56.192903+00:00] console.CRITICAL: Error thrown while running command "ngscheduledvisibility:update". Message: "Warning: DOMDocument::loadXML(): xml:id : attribute value 146092 is not an NCName in Entity, line: 2" {"exception":"[object] (ErrorException(code: 0): Warning: DOMDocument::loadXML(): xml:id : attribute value 146092 is not an NCName in Entity, line: 2 at /mnt/data/htdocs/ib46-fide/vendor/ibexa/fieldtype-richtext/src/lib/FieldType/RichText/RichTextStorage.php:139)","command":"ngscheduledvisibility:update","message":"Warning: DOMDocument::loadXML(): xml:id : attribute value 146092 is not an NCName in Entity, line: 2"} []
It looks like an xml object is not valid. We imported some articles and converted the ezxml items with the ibexa utility.
.... 1. we think a script which is updating the visibility status of an object should not break if something is wrong in an richtextfield
=> the script should be ignore the problem objects and process the other objects.
we don't know which object can not be processed => an extended log or view of the processing item would be good to have (maybe a verbose option which output the processing items with date publish_from => publish_to and id + name would be helfpfull
I don't know how the output looks like if it processed an item successfully and reveal it ... in that case a console output could be usefull too with contentid/locationId publish_from publish_to and name
This output can than be piped in cronjob logfile
Or we have an extra logfile for that. So that you can say when an article was made visible or unvisible by cronjob ...
The text was updated successfully, but these errors were encountered:
Now fixed in c261c7b, you can install it as dev-master version
Also solved through 1., all loading errors are now being caught and logged
All changes to visibility are already logged to a separate channel ngscheduledvisibility, which can be configured through Monolog configuration to be stored to a separate file. This is documented at https://symfony.com/doc/current/logging/channels_handlers.html, but we didn't implement it here as we assumed it's out of the scope of this bundle to decide how exactly that should be done in each case. Would that be sufficient for you?
Hi,
we did some testing on our installation, and if i run the update script:
php bin/console ngscheduledvisibility:update --no-interaction
we get the following warning which produces an error log item:
[2024-06-27T11:58:56.192903+00:00] console.CRITICAL: Error thrown while running command "ngscheduledvisibility:update". Message: "Warning: DOMDocument::loadXML(): xml:id : attribute value 146092 is not an NCName in Entity, line: 2" {"exception":"[object] (ErrorException(code: 0): Warning: DOMDocument::loadXML(): xml:id : attribute value 146092 is not an NCName in Entity, line: 2 at /mnt/data/htdocs/ib46-fide/vendor/ibexa/fieldtype-richtext/src/lib/FieldType/RichText/RichTextStorage.php:139)","command":"ngscheduledvisibility:update","message":"Warning: DOMDocument::loadXML(): xml:id : attribute value 146092 is not an NCName in Entity, line: 2"} []
It looks like an xml object is not valid. We imported some articles and converted the ezxml items with the ibexa utility.
....
1. we think a script which is updating the visibility status of an object should not break if something is wrong in an richtextfield
=> the script should be ignore the problem objects and process the other objects.
we don't know which object can not be processed => an extended log or view of the processing item would be good to have (maybe a verbose option which output the processing items with date publish_from => publish_to and id + name would be helfpfull
I don't know how the output looks like if it processed an item successfully and reveal it ... in that case a console output could be usefull too with contentid/locationId publish_from publish_to and name
This output can than be piped in cronjob logfile
Or we have an extra logfile for that. So that you can say when an article was made visible or unvisible by cronjob ...
The text was updated successfully, but these errors were encountered: