Hi all,
I’m trying to upgrade a 2.8.4-pl site to 3.0.1-pl.
I am doing this on a staging version of the existing site.
Each time I carried out the upgrade I had various issues, errors on the dashboard and the Package Manager would not load the list of extras installed.
I troubleshot this partly with the help of this thread .
I got so far but I still couldn’t get the Package Manager to list the Extras.
So, I started again and uninstalled ALL extras from the staged site in 2.8.4-pl and ran the update again.
This time the Manager issues were gone.
I reinstalled all the necessary extras and the Manager looks great
However, on the front end, some MODX tags are not getting parsed.
[[++system_setting_name]] tags seem fine.[[$chunk_name]] tags seem fine.[[snippet_name]] tags are not parsed.[[*placeholder_name]] tags are not parsed.
So, the front-end rendering of my pages is just full of unparsed snippet calls and placeholders.
Eg,
The error log is clear and the cache has been cleared.
Anyone know what’s going on here?
Chris
Does this only happen for uncached tags ([[! ... ]] ) or for cached tags ([[ ... ]] ) as well?
There have been other threads where tags were output to the frontend unprocessed. Like this one:
SepiaRiver’s Example Blog which worked fine on MODX 2.8. She now (accidentally) updated MODX to v3 and I now have to fix stuff…
After “repairing” the Namespacing issues, it still seems that generated MODX tags with an exclamation mark (for no caching) don’t work anymore—instead the tag is displayed on the web page.
I have no clue why this occurs. Theoretically all the tags should get removed, even if they can’t be processed.
if (!empty($data)) {
$scope = $this->xpdo->toPlaceholders($data, '', '.', true);
}
if (!$this->_processed) {
$this->_content = $this->getContent();
$this->xpdo->parser->processElementTags('', $this->_content, false, false, '[[', ']]', [], $maxIterations);
$this->_processed = true;
}
$this->_output = $this->_content;
$this->xpdo->parser->processElementTags('', $this->_output, true, false, '[[', ']]', [], $maxIterations);
$this->xpdo->parser->processElementTags('', $this->_output, true, true, '[[', ']]', [], $maxIterations);
$this->xpdo->resource = $oldResource;
if (isset($scope['keys'])) {
$this->xpdo->unsetPlaceholders($scope['keys']);
}
if (isset($scope['restore'])) {
$this->xpdo->toPlaceholders($scope['restore']);
}
return $this->_output;
}
Good question.
It looks like only uncached snippet calls seem to fail.
So, contrary to my first post,
[[snippet_name]] is parsed
[[!snippet_name]] is not parsed
Can you test if the function parseContent (I linked above) of the class modResource even gets executed?
You could (temporarily) add a log statement to the code
$this->xpdo->log(modX::LOG_LEVEL_ERROR, 'function parseContent executed. Resource-ID=' . $this->get('id'));
and then check the MODX error log if the line gets output, when you refresh the page on the frontend.
Added your line after L522.
Refreshed resource ID 1 on front end.
Error Log:
[2022-06-03 17:07:49] (ERROR @ /home/xxyyzz/2022/stage5/core/src/Revolution/modResource.php : 523) function parseContent executed. Resource-ID=1
Oddly, if I add an uncached snippet to a new template and apply that template to a new resource, it works.
Are the unprocessed tags nested inside other tags? Maybe with output modifiers?
No, I’ve stripped it right back and am testing the uncached snippet tags in the top-level templates.
Applying the new template to the original problem Resource #1 - the tag is processed.
So is it template-specific?
I’m grateful for your help @halftrainedharry - I may need to stop troubleshooting for a bit but will try to get back to it later.
I don’t see what in the template would change the behaviour of the parser.
Are there any differences between the old and the new template in the database?
This is all very weird.
dejaya
June 3, 2022, 6:57pm
10
OK - progress!
In my original template I have the following line in the HTML <head>:
[[*meta-description:default=`[[!stripTags? &content=`xxyyzz`]]`]]
This line returns:
[[!stripTags? &content=
and prevents every following uncached snippet call from being processed.
It only happens when the above snippet call is uncached and only when it’s in the output modifier . If either of those are not true - all the following uncached snippet calls work fine.
So these do not cause problems:
[[*meta-description:default=`[[stripTags? &content=`xxyyzz`]]`]]
[[!stripTags? &content=`xxyyzz`]]
I think that points us to this issue .
It seems that almost every problem with MODX 3 points to that issue.
You could test it, by replacing this line in the code
public function filter(&$element)
{
/* split commands and modifiers and store them as properties for the output filtering */
$output = $element->get('name');
$name = $output;
$splitPos = strpos($output, ':');
if ($splitPos !== false && $splitPos > 0) {
$matches = [];
$name = trim(substr($output, 0, $splitPos));
$modifiers = substr($output, $splitPos);
if (preg_match_all('~:([^:=]+)(?:=`((?:(?:[^:=][\s\S]*?|(?R))*?))`)?~s', $modifiers, $matches)) {
$this->_commands = $matches[1]; /* modifier commands */
$this->_modifiers = $matches[2]; /* modifier values */
}
}
$element->set('name', $name);
}
/**
* Indicates if the element has any input filter commands.
*
with the value from MODX 2.x:
if (preg_match_all('~:([^:=]+)(?:=`(.*?)`[\r\n\s]*(?=:[^:=]+|$))?~s', $modifiers, $matches)) {
dejaya
June 3, 2022, 8:28pm
12
Aye - that seems to fix it
