7

After updating to Craft 2.6.2778, my plugin is causing these deprecation errors:

PathService::getTemplatesPath() has been deprecated. Use TemplatesService::getTemplatesPath() or TemplatesService::getTemplateMode() instead.

PathService::setTemplatesPath() has been deprecated. Use TemplatesService::setTemplatesPath() or TemplatesService::setTemplateMode() instead.

How do I fix these?

Community
  • 1
Brandon Kelly
  • 34,307
  • 2
  • 71
  • 137

2 Answers2

6

PathsService::getTemplatesPath() and setTemplatesPath() were deprecated in Craft 2.6.2778. They were commonly used by Craft and plugins to render front-end templates from the Control Panel (or vise-versa).

We realized that there were cases where simply changing the root templates path was insufficient to emulate front-end requests in the CP, though. For example, if defaultTemplateExtensions was being overridden to:

'defaultTemplateExtensions' => array('htm'),

and the CP was trying to find a “test” template which was supposed to resolve to test.htm, a CP request would not actually be able to find the template, because CP requests are only looking for templates that end in .twig and .html.

So in 2.6.2778 we’ve resolved this with “template modes”, which provide an explicit way to tell Craft to render a front-end template vs. a CP template, rather than simply telling it to use a different base template directory.

Updating your plugin code is pretty simple. Just change things like this:

$oldPath = craft()->path->getTemplatesPath();
craft()->path->setTemplatesPath(craft()->path->getSiteTemplatesPath());

// ...

craft()->path->setTemplatesPath($oldPath);

to this:

$oldMode = craft()->templates->getTemplateMode();
craft()->templates->setTemplateMode(TemplateMode::Site);

// ...

craft()->templates->setTemplateMode($oldMode);
André Elvan
  • 7,288
  • 22
  • 34
Brandon Kelly
  • 34,307
  • 2
  • 71
  • 137
  • Is this change backwards compatible? If so, to what version of Craft will it work? I'm faced with a number of plugins that need to work on 2.4.x, 2.5.x, and 2.6.x. I'd like to fix the deprecation errors without breaking the plugin on older Craft CMS installs. – andrew.welch Mar 29 '16 at 19:04
  • @khalwat No, the new methods didn’t exist until 2.6.2778. You could use conditional logic based on the Craft build (craft()->getBuild()) – if less than 2778 use the deprecated PathService methods, but personally I’d just recommend telling people that the new version of your plugin requires Craft >= 2.6.2778. – Brandon Kelly Mar 29 '16 at 19:07
  • 2
    That's unfortunate. I may have other critical fixes/features they want to take advantage of, but they may be using an older Craft version for a variety of reasons. I assume your stats show that the adoption rate of new releases is pretty good, but I think I'll err on the side of backwards compatibility here and try to do different things based on the Craft version or perhaps I can check for the availability of the methods instead. – andrew.welch Mar 29 '16 at 19:19
  • I have to agree with @khalwat on this... It seems crazy to require a random build as the new minimum version, and forgo any backwards compatibility. On the other hand, continuously dealing with support tickets over a deprecation error is not a good solution either. :( – Lindsey D Mar 29 '16 at 21:32
  • Annoying deprecation notices notwithstanding... Why is setting the template path mutually exclusive from setting the template rendering mode? I understand how it makes sense to be able to switch the the index/extension settings based on the context... adding Template Contexts makes sense. But why does that necessitate deprecating setTemplatesPath()? – Michael Rog Mar 29 '16 at 22:03
  • @MichaelRog It’s still possible to explicitly change the root templates path independently of the template mode. getTemplatesPath() and setTemplatesPath() have been “moved” to TemplatesService (where they should have been all along), and the old PathService methods are now just deprecated wrappers for the new TemplatesService methods. We just think in most cases, setting the template mode is more appropriate. – Brandon Kelly Mar 29 '16 at 22:07
  • Oh... duh. I didn't realize that those hadn't been in TemplatesService all along. Cool. – Michael Rog Mar 29 '16 at 22:09
4

You can do something like this:

$oldPath = method_exists(craft()->templates, 'getTemplatesPath') ? craft()->templates->getTemplatesPath() : craft()->path->getTemplatesPath();
method_exists(craft()->templates, 'setTemplatesPath') ? craft()->templates->setTemplatesPath($newPath) : craft()->path->setTemplatesPath($newPath);

...and then to restore it:

method_exists(craft()->templates, 'setTemplatesPath') ? craft()->templates->setTemplatesPath($oldPath) : craft()->path->setTemplatesPath($oldPath);

Since craft()->path->templatesPath ends up calling craft()->path->getTemplatesPath() so you have to fix any instances of that as well.

If you're dealing with this issue, your choices are:

  1. Do nothing and have it spew “alarming” deprecation errors to admin when running Craft 2.6.2778 or later.
  2. Update it to the new code, and say your plugin requires 2.6.2778 (and have it break on all previous versions of Craft).
  3. Use the code I posted above to check for the methods existing, and use them if they are there.

TBH, I think deprecation errors shouldn't be on the Dashboard. Admins log in and see a big scary message they've never seen before, and realistically, they can't do anything about it other than trying to update a plugin or contact the developer. Plugin developers know where to look for deprecation notices, but even more handy perhaps would be runtime deprecation warnings/errors when devMode is on.

andrew.welch
  • 11,551
  • 22
  • 31