CiviCRM Community Forums (archive)

scubaguy,

It appears that the path is wrong, but I'm not sure where to change it.  The path to both files should be:
templates/CRM/common/jquery.files.tpl
templates/CRM/common/success.tpl

-- It is searching for the correct files. For template files it will correctly append the  ' templates/ ' part. The issue is something different. I guess its permission issue. can you check the permission of code base once again. (readable)

HTH

Rahul.

I had a similar problem with Smarty class when upgrading a test site to 3.3.1alpha and I found a fix - unfortunately, I found the fix while working feverishly late at night so I don't remember exactly what worked, and I ended up doing a fresh 3.3.1alpha install for unrelated reasons so I can't check back. (fresh install worked fine btw).

I do remember some of things I tried: the two that stick in my mind as having helped most were loosening permissions on directories, files and also parent directories (which I imagine you've tried), and liberally scattering symlinks to the relative folder it was looking for in every possible incorrect base directory, including several non-obivous ones (I think [drupalroot]/sites/default/files/civicrm of all places might have done it in the end - crazy but possibly related to issue below. Could be wrong).

I've done some unrelated work since with 3.3.1alpha and I noticed that a lot of directory related options are now in the option_values and option_groups tables on the database, and they weren't before in 3.2. Some of these fields seem to be system controlled and not controlled through the interface, and under some circumstances, the GUI shows correct looking values under 'Global settings > Directories' when actually there's nothing in the database: it's like it's generating them on the fly on each config page load based on the civicrm.settings.php value then failing to save them to the database. This can give the impression that Civi3.3's directories are correctly configured when actually they aren't at all.

If my above suggestion doesn't work, I'd recommend checking out these tables and comparing them to what's generated during a clean install. It's possible the upgrade script is getting these mixed up. Most likely there's probably a trailing slash somewhere in your upgraded DB where there's none in the fresh install

I got the same error, but on an upgrade from 3.2.4 to 3.3 beta2.In my case, I had an early version of CiviEngage previously installed but inactive - seeing that CiviEngage was now included in 3.3, I removed the old civicrm_engage folder before performing the upgrade.

When I disabled CiviEngage in 3.3, the error went away.

This is a live site and I'm using Better Messages, so I couldn't copy the error text. I did a screen capture and I see that it's looking for CRM/common/jquery/jquery.files.tpl (for example)  when it should be looking for templates/CRM/common/jquery/jquery.files.tpl. This is for about 20 files.

Has anybody figured out the necessary change to get Civi to point to the right location here? Thanks!

See possible fix here:

http://forum.civicrm.org/index.php?topic=16894.new;topicseen#new

Our CiviCRM installation had this error appear on upgrading to ver 3.3. 

For whatever reason, the directory for engage (under civicrm/drupal/modules) had been renamed to civicrm_engage2.

Changing the name to civicrm_engage fixes the problem (and changing it back to civicrm_engage2 brings the problem back instantly!).

Not sure why, but there you go . . .