01408: ROSPatterns not applied to Preview
Description: If you have markup that is based on an Replace On Save pattern, that markup does not get applied when a user selection "Preview" from the edit page.
Example: Set:
$ROSPatterns['/XXX/']='YYY'; $ROEPatterns['/YYY/']='XXX'; Markup('previewtest', 'markup', '/YYY/', '3Xs');
So a user should be able to write XXX and have "3Xs" show up. But if a user selects "Preview" from the edit screen, the preview will show XXX and not 3Xs.
Possible approach to solution?
function ReplaceOnSave (called via UpdatePage) contains
if ($EnablePost) { $t = PPRA((array)@$ROSPatterns, $t); }
So, despite the name of the function, ReplaceOnSave doesn't do the replacements unless $EnablePost is actually set. Is there any reason not to do the replacement for every call?
So one could have:
$t = PPRA((array)@$ROEPatterns, $t); // Necessary for templates $t = PPRA((array)@$ROSPatterns, $t);
I don't know if there are any side effects of this, but the core functionality doesn't use ReplaceOnSave anywhere else.
Workaround:
scripts/author.php gets around this problem by defining Markup('~~~','>~~~~','/(?<!~)~~~(?!~)/',"$Author");@] so even though ~~~ should never appear in a file, the markup appears. This is inelegant and would require more effort from recipe authors (if they are aware of the problem) but works.
Peter Kay May 03, 2017, at 12:07 PM
If you press Preview, the page is not saved, so the replacement must not happen. If you want to have replacements on Preview, use $ROEPatterns
. --Petko May 03, 2017, at 12:53 PM
$ROSPatterns
(although it is indeed clearly stated so in the code). I posted this under the working assumption that "Preview" was meant to show the user exactly what the page would look like if they hit "Save" - but if there are any recipes using $ROSPatterns
, this will not be the case unless the recipe author has explicitly planned for it.
$ROSPatterns
needs to be updated so that any potential authors know they may need to run their markup twice - once replacing the markup for writing, and once for preview. I would vote for having the Preview functionality mirror exactly what a saved page looks like:
- A cookbook author can easily check if a preview is happening if it's important to the workflow. (e.g., perhaps a callback that sends an email when a pattern gets saved)
- Most authors wouldn't care, and it would be less work for authors to have Preview apply
$ROSPatterns
.
$ROEPatterns
goes, I was under the impression that they are used when loading a page into the editor for the user: the pattern replacement affects what the user sees in the edit text box?
I agree Preview should show what the page would look like if you saved it. So PreviewPage() should process $ROSPatterns
at that point (added for 2.2.99). --Petko June 01, 2017, at 11:56 PM