Why? src/common is not a namespace and I believe TwigExtension.php is new to v6 so may not be loaded by autoloader so instantiation relies on namespace. At any rate, delete the src/common(lowercase) directory.
I’ve installed this patch numerous times(both new install and upgrade) and haven’t seen this however, who knows right!
Hmm, I don’t know, check out how much stuff I have in src/Common:
It seems to have been installed/updated 1/15/22 with the “6-0-0-Patch-3” update.
I am hesitant to delete it.
Commenting out lines 331 and 478 in openemr/templates/portal/home.html.twig did the trick, but what portal functionality am I missing out on by doing that?
This is the contents of lower case src/common:
…Oh, wait a minute, ok yes, I will delete the lower case one.
Leave the uppercase src/Common alone. I said delete the lowercase directory src/common!
Patching out the event dispatch won’t hurt anything in portal and is there for module developers.
Still you shouldn’t have to do this.
Looks like I created the lowercase common directory in my prepatch portal_patch_v6.0.4 so anyone who installed this should delete the directory. Sorry everyone!
Strange how nobody else has seen this.
It may be related to my setup. Remember that I use FreeBSD.
This is the stack trace in case it tells you anything:
[21-Feb-2022 23:40:34 America/New_York] PHP Fatal error:
Uncaught Twig\Error\SyntaxError: Unknown "fireEvent" function. in
/path/to/openemr/templates/portal/home.html.twig:331
Stack trace:
#0 /path/to/openemr/vendor/twig/twig/src/ExpressionParser.php(460): Twig\ExpressionParser->getFunctionNodeClass()
#1 /path/to/openemr/vendor/twig/twig/src/ExpressionParser.php(235): Twig\ExpressionParser->getFunctionNode()
#2 /path/to/openemr/vendor/twig/twig/src/ExpressionParser.php(175): Twig\ExpressionParser->parsePrimaryExpression()
#3 /path/to/openemr/vendor/twig/twig/src/ExpressionParser.php(70): Twig\ExpressionParser->getPrimary()
#4 /path/to/openemr/vendor/twig/twig/src/Parser.php(142): Twig\ExpressionParser->parseExpression()
#5 /path/to/openemr/vendor/twig/twig/src/TokenParser/BlockTokenParser.php(45): Twig\Parser->subparse()
#6 /path/to/openemr/vendor/twig/twig/src/Parser.php(185): Twig\TokenParser\BlockTokenParser->parse()
#7 /path/to/openemr/vendor/twig/twig/src/Parser.php(98): Twig\Parser->subparse()
#8 /path/to/openemr/vendor/twig/twig/src/Environment.php(563): Twig\Parser->parse()
#9 /path/to/openemr/vendor/twig/twig/src/Environment.php(595): Twig\Environment->parse()
#10 /path/to/openemr/vendor/twig/twig/src/Environment.php(408): Twig\Environment->compileSource()
#11 /path/to/openemr/vendor/twig/twig/src/Environment.php(381): Twig\Environment->loadClass()
#12 /path/to/openemr/vendor/twig/twig/src/Environment.php(359): Twig\Environment->loadTemplate()
#13 /path/to/openemr/vendor/twig/twig/src/Environment.php(318): Twig\Environment->load()
#14 /path/to/openemr/portal/home.php(287): Twig\Environment->render()
#15 {main}
thrown in /path/to/openemr/templates/portal/home.html.twig on line 331No trace is fine as far as I see.
Windows doesn’t care about folder name case so I can’t duplicate. Did you delete the src/common and did that fix?
I did, delete the correct directory, but it did not fix my problem.
What fixes it is commenting out the two lines, as I mentioned above. I also changed the permissions to 0755 for TwigExtension.php, but also did not fix the problem.
If you have composer installed open a terminal/command line in openemr directory and run
composer dump-autoload -o
I installed php80-composer2, ran your suggestion above, and got this error:
Generating optimized autoload files
Class OpenEMR\Common\Twig\TwigContainer located in ./src/common/Twig/TwigContainer.php does not comply with psr-4 autoloading standard. Skipping.
Class OpenEMR\Common\Twig\TwigExtension located in ./src/common/Twig/TwigExtension.php does not comply with psr-4 autoloading standard. Skipping.
Class OpenEMR\Common\Auth\AuthGlobal located in ./src/common/Auth/AuthGlobal.php does not comply with psr-4 autoloading standard. Skipping.
Generated optimized autoload files containing 5848 classes
Running composer did not fix the problem either. I again commented out the lines above.
In the above line its still looking like you have a common folder on your file system which should not be there. Did you delete the wrong directory? The lowercase folder name should have been deleted with the uppercase Common folder left.
Correct, I deleted the lower case common directory.
Ok, this page has been updated
https://www.open-emr.org/wiki/index.php?title=Patient_Portal_Document_Templates
So I noticed the tags are in alphabetical order, so that’s what I did, with the version number in parenthesis (v6.0.1).
The only tag I could not figure out, was the {GRP}{/GRP}
Perhaps I just need a little more clarification.
@gutiersa
Best I can tell GRP allows grouping LBF fields.
Tag indicates the fields from {GRP} until {/GRP} are a group of fields
separated by semicolons. Fields with no data are omitted, and fields with
data are prepended with their field label from the form layout
I see. It seems to me that it is a useful tag then. Leave it then?
this is a sample in the portal dashboard, and below is how it renders:
I update the wiki, but not sure how to upload images there.
This might be a bug:
Here is how my profiles window shows:
On the right hand side, the name of the template is not shown only the category!
Sandra. Truncate document_template_profiles and try. If that fails delete document_template_profiles and run upgrade again.
It worked!
Let me follow it up with some images below
At any rate for anyone else with a problem and who has access to the database (MySQL in my case), this is what I did:
At command prompt,
MySQL -u root -p database_name
user@localhost [database_name]> truncate document_template_profiles;
This is what a brand new/empty profile table looks like (after truncating the table). It includes sample template documents on the left:
To move templates to the right, just drag any template from the left and drag it to the right:
and,
One template may belong to one or more profiles:
So were you able to recover your data by running the upgrade script?
she was most likely usng an early version of the table from testing and was missing the index
