I am trying to get Smarty setup and working, so that I can install the open-source project here
http://sourceforge.net/projects/assign-calc/
After following the install instructions, I get stuck with the following error message
<b>Fatal error</b>: Uncaught exception 'SmartyCompilerException' with message 'Syntax Error in template "/var/www/dev/calendar/skins/rpc/tmpl/page/rpc_header.tpl" on line 5 " {$application.long_name|escape}" unknown modifier "escape"' in /usr/lib/php5/Smarty/Smarty/sysplugins/smarty_internal_templatecompilerbase.php:423
Stack trace:
#0 /usr/lib/php5/Smarty/Smarty/sysplugins/smarty_internal_compile_private_modifier.php(62): Smarty_Internal_TemplateCompilerBase->trigger_template_error('unknown modifie...', 5)
#1 /usr/lib/php5/Smarty/Smarty/sysplugins/smarty_internal_templatecompilerbase.php(279): Smarty_Internal_Compile_Private_Modifier->compile(Array, Object(Smarty_Internal_SmartyTemplateCompiler), Array, NULL, NULL)
#2 /usr/lib/php5/Smarty/Smarty/sysplugins/smarty_internal_templatecompilerbase.php(123): Smarty_Internal_TemplateCompilerBase->callTagCompiler('private_modifie...', Array, Array)
#3 /usr/lib/php5/Smarty/Smarty/sysplugins/smarty_internal_compile_private_print_expression.php(68): Smarty_Internal_TemplateCompilerBase in <b>/usr/lib/php5/Smarty/Smarty/sysplugins/smarty_internal_templatecompilerbase.php</b> on line <b>423</b><br />
After a bit of googling, I think the problem is being cause by Smarty not reading the escape modifier in the plugins directory.
How do I resolve this? I've even tried 777 the permissions on smarty, but that hasnt change anything...
Have you loaded the smarty configuration correctly? In particular, have you setted correctly the plugin path, through the command
$smarty->addPluginsDir('path/to/plugins');
?
I'm the developer of the Research Project Calculator, and found this SO question while researching the same problem for another user. The code has only been in the wild for a few weeks and we're discovering some of these things as other institutions install it.
I was able to get it running for the other user by explicitly calling parent::__construct(); before anything else in the inc/rpc_smarty.inc.php class constructor. I'll post a new release shortly, but for now you should just be able to patch that constructor as below.
Please feel free to contact me via the link in the project's installation instructions wiki page if you have more questions or run into other problems.
public function __construct($config)
{
parent::__construct();
$this->config = $config;
...
...
}
An absolute system path is the fastest and safest approach. You can use relative paths, but be certain the php include_path contains what is needed to find it. You could also use SMARTY_DIR to base your path from.
Related
Cross post from https://github.com/getgrav/grav/issues/3523
(don't kill me, I didn't know that it's frowned upon)
I am not sure if this is the place to ask for help, so tell me if it's not (and maybe where to ask).
I am trying to update to the latest Grav release 1.7.29 from (originally 1.6.24, while troubleshooting today updated to) 1.6.31 (using direct-install.
I tried updating with self-upgrade and direct-install <latestVersionURL>.
But, while trying to install, it gives me the following error:
Installing upgrade... [30-Jan-2022 17:04:37 Europe/Cityxy] PHP Fatal
error: Uncaught Error: Call to undefined method
Grav\Common\Utils::basename() in
/var/www/virtual/name/html/tmp/Grav-61f6b713f0bb9/zip/grav-update/system/src/Grav/Installer/VersionUpdate.php:29
Stack trace:
#0 /var/www/virtual/name/html/tmp/Grav-61f6b713f0bb9/zip/grav-update/system/src/Grav/Installer/VersionUpdater.php(126):
Grav\Installer\VersionUpdate->__construct('/var/www/virtua...',
Object(Grav\Installer\VersionUpdater))
#1 /var/www/virtual/name/html/tmp/Grav-61f6b713f0bb9/zip/grav-update/system/src/Grav/Installer/VersionUpdater.php(38):
Grav\Installer\VersionUpdater->loadUpdates()
#2 /var/www/virtual/name/html/tmp/Grav-61f6b713f0bb9/zip/grav-update/system/src/Grav/Installer/Install.php(239):
Grav\Installer\VersionUpdater->__construct('core/grav',
'/var/www/virtua...', '1.7.29', Object(Grav\Installer\Versions))
#3 /var/www/virtual/name/html/tmp/Grav-61f6b713f0bb9/zip/grav-update/system/src/Grav/Installer/Install.php(184):
Grav\Installer\Install->prepare()
#4 /var/www/virtual/name/html/system/src/Gra in /var/www/virtual/eduref/html/tmp/Grav-61f6b713f0bb9/zip/grav-update/system/src/Grav/Installer/VersionUpdate.php
on line 29
From my understanding the files between versions have been changed, and looking at the Grav documentation, the called method basenames() is now in Grav/Common/URI, not in Grav/Common/Utils.
So I assume I located the problem, but have no idea on fixing it. Since I am not very well versed on this whole topic of managing websites (never set up the site, only maintaining it), I would really appreciate a safe answer on how to update Grav to the newest version which doesn't risk me destroying the functioning of the website.
Thank you for helping! :)
Tried with:
PHP: 7.3 & 7.4
Grav: 1.6.24 & 1.6.31
Admin: 1.9.10
Host: Uberspace
via SSH
Particular issue fixed:
https://github.com/getgrav/grav/issues/3523
following issue open:
https://github.com/getgrav/grav/issues/3532
I'm writing a very basic catenation script and lifted this straight off the pdftk 0.10.0 packagist site:
use mikehaertl\pdftk\Pdf;
// Extract pages 1-2 into a new file
$pdf = new Pdf('sourcefile.pdf');
$result = $pdf->cat(1, 2)
->saveAs('newfile.pdf');
if ($result === false) {
$error = $pdf->getError();
}
But I'm getting this error:
Fatal error: Uncaught Error: Class "mikehaertl\pdftk\Pdf" not found in C:\PHP8\index.php:7 Stack trace: #0 {main} thrown in C:\PHP8\index.php on line 7
All the sample scripts I've seen have that same header. I'm sure it's something really basic that I'm not seeing here.
Since the error is showing the Class not found, it would make me initially think that the package wasn’t installed in your project. If you run composer require mikehaertl/php-pdftk, does that get you rolling?
If you’re not familiar with Composer, here’s a quick guide to getting started: https://packagist.org/
Apparently, when installed via composer, the pdftk.exe file is not downloaded for some reason. I downloaded it manually from the github page and referred to it in the header.
Ok, finally found the answer. You need to install pdftk beforehand as packagist does not automatically pull it for you.
I'm running drupal 8, composer and npm to perform gulp tasks.
When I run npm start.. my task manager: I get the following stack trace:
Fatal error: Uncaught exception 'Twig_Error_Syntax' with message 'Unknown "render" filter.' in /web/project/web/themes/emulsify/components/_patterns/04-templates/basic-page/_basic_page.twig:26
Stack trace:
#0 /web/project/web/themes/emulsify/pattern-lab/vendor/twig/twig/lib/Twig/ExpressionParser.php(481): Twig_ExpressionParser->getFilterNodeClass('render', 26)
#1 /web/project/web/themes/project_theme/pattern-lab/vendor/twig/twig/lib/Twig/ExpressionParser.php(466): Twig_ExpressionParser->parseFilterExpressionRaw(Object(Twig_Node_Expression_Name))
#2 /web/project/web/themes/project_theme/pattern-lab/vendor/twig/twig/lib/Twig/ExpressionParser.php(320): Twig_ExpressionParser->parseFilterExpression(Object(Twig_Node_Expression_Name))
#3 /web/project/web/themes/project_theme/pattern-lab/vendor/twig/twig/lib/Twig/ExpressionParser.php(212): Twig_ExpressionParser->parsePostfixExpression(Object(Twig_Node_Expression_Name))
#4 /web/project in /web/project/web/themes/project_theme/components/_patterns/04-templates/basic-page/_basic_page.twig on line 26
I've looked at installing twig-bridge / symfony twig via composer but I can't seem to get rid of the error message.
Do I just ditch using the twig filter "render"?
Update: 14/08/17
I've also ran into the same problem when trying to use the drupal_block function provided via Drupal 8's twig_tweak module.
The problem in the code above is that your Twig extension class is extending the internal Drupal Twig extension class. That breaks the Twig extensions added by Drupal core and that's why you are getting the error.
To fix this, you should make your Twig extensions extend Twigs internal Twig extension class. Your class should be defined like this:
class MyExtension extends \Twig_Extension {
After making that change, you can also remove arguments set for that class from the MODULE.services.yml
link
I've not seen this in the Drupal context, but working with other platforms that use Twig, I have seen similar issues occurring when an error occurs early in the platform setup process.
The typical sequence of events is like this:
The platform starts running its bootup; loading the CMS core, etc.
At some point early in this process, it hits an error.
It then tries to render an error page.
However, the error page uses a Twig template.
The startup process has not yet loaded all the twig extensions used in the template.
Boom, you get a twig error stating "unknown Twig function" instead of the real error message.
When I've had this before, it has proved very hard to diagnose what the actual error is.
The "correct" solution has been to modify the error page templates so that they are minimal and don't use any non-core twig functions. But if you're getting a crash early in the page load process it can be hard to actually do that.
In the first case, I resolved it by debugging the system and trapping what data was passed to the template. This showed me what the real error was. Resolving that error then stopped the twig error from occurring and allowed me to get into the system.
I don't know for sure if what you're seeing is the same kind of thing as what I was seeing, but it sounds similar so I hope this will help.
I am trying to upgrade Moodle 2.7 to 3.1.But for some reason I can't. This is the error:
Coding error detected, it must be fixed by a programmer: The data source class does not exist.
Debug info:
Error code: codingerror
Stack trace:
line 498 of /cache/classes/definition.php: coding_exception thrown
line 515 of /cache/classes/helper.php: call to cache_definition::load()
line 480 of /cache/classes/helper.php: call to cache_helper::purge_store()
line 323 of /admin/index.php: call to cache_helper::purge_all()
What could be the problem of this?
I just had the exact same problem trying to update from version 2.8 to 3.1, I found the solution in this Moodle Tracker issue:
Removed the following directories (and let Moodle rebuild them),
cache, lock, temp, trashdir, sessions, localcache, muc (and anything
else that shouldn't have been in there). Obviously don't delete your
files/filedir!
I leave the solution in case someone else has this problem.
cd /var/moodledata
rm -fr ./cache/ ./lock/ ./temp/ ./trashdir/ ./sessions/ ./localcache/ ./muc/
You may have removed a file which was meant to be included when loading the cache definitions from any db/caches.php. Grep those files for datasource, that will help you identify where the problem is.
Another reason would be that the class cannot be found because the cache code runs before the autoloading definitions are set. That would be very surprising, but you can have a look at [moodledatafolder]/cache/core_component.php to see if the class is in there, and its path exists.
I've been developing WordPress sites for a long time on my local MAMP server. Now all of a sudden, it won't let me create any new sites. Whenever I set up a new one, instead of running the install script I get:
Fatal error: Cannot redeclare class
wpdb in
/Applications/MAMP/htdocs/[my_site]/wp-includes/wp-db.php
on line 52
This happens with all WordPress versions. I cannot thing of anything that would have caused this. I've done everything short of re-install MAMP. Does anyone have any ideas? I'm desperate at this point..
Check out the include path for php. It's likely that a second instance of wordpress is on the include path and is therefore conflicting with the one you're trying to load. It's also possible that a different package on the include path has a class called wpdb and is therefore causing a conflict.
wpdb is being created again some where, if this happened all of a sudden i suggest that you disable any plugins you've recently added. Or even better do a global find for the term class wpdb and see if that appears within more than 1 file. Also, check your functions.php file for a loop that might be loading wp-db.php more than once.
A workaround fix is to wrap the wpdp class in wp-includes/wp-db.php in the following:
Line 52:
if(class_exists('wpdb') != true)
{
class wpdb {
...
}
}
This solved the install issue- You could probably remove it after that, although it can't hurt to leave it I guess.
Still don't understand why this problem has popped up- If someone has an explanation I'd be eager to hear it.