<p>You can do something like this:</p>

<pre><code>$oldPath = method_exists(craft()-&gt;templates, 'getTemplatesPath') ? craft()-&gt;templates-&gt;getTemplatesPath() : craft()-&gt;path-&gt;getTemplatesPath();
method_exists(craft()-&gt;templates, 'setTemplatesPath') ? craft()-&gt;templates-&gt;setTemplatesPath($newPath) : craft()-&gt;path-&gt;setTemplatesPath($newPath);
</code></pre>

<p>...and then to restore it:</p>

<pre><code>method_exists(craft()-&gt;templates, 'setTemplatesPath') ? craft()-&gt;templates-&gt;setTemplatesPath($oldPath) : craft()-&gt;path-&gt;setTemplatesPath($oldPath);
</code></pre>

<p>Since <code>craft()-&gt;path-&gt;templatesPath</code> ends up calling <code>craft()-&gt;path-&gt;getTemplatesPath()</code> so you have to fix any instances of that as well.</p>

<hr>

<p>If you're dealing with this issue, your choices are:</p>

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

<p>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 <code>devMode</code> is on.</p>

CC BY-SA 3.0
2016-03-29T21:08:10.040Z
2016-03-29T22:28:17.740Z
2016-03-29T22:28:17.740Z
andrew.welch
<p><a href="https://craftcms.com/classreference/services/PathService#getTemplatesPath-detail">PathsService::getTemplatesPath()</a> and <a href="https://craftcms.com/classreference/services/PathService#setTemplatesPath-detail">setTemplatesPath()</a> 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).</p>

<p>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 <a href="https://craftcms.com/docs/config-settings#defaultTemplateExtensions">defaultTemplateExtensions</a> was being overridden to:</p>



<pre class="lang-php prettyprint-override"><code>'defaultTemplateExtensions' =&gt; array('htm'),
</code></pre>

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

<p>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.</p>

<p>Updating your plugin code is pretty simple. Just change things like this:</p>

<pre class="lang-php prettyprint-override"><code>$oldPath = craft()-&gt;path-&gt;getTemplatesPath();
craft()-&gt;path-&gt;setTemplatesPath(craft()-&gt;path-&gt;getSiteTemplatesPath());

// ...

craft()-&gt;path-&gt;setTemplatesPath($oldPath);
</code></pre>

<p>to this:</p>

<pre class="lang-php prettyprint-override"><code>$oldMode = craft()-&gt;templates-&gt;getTemplateMode();
craft()-&gt;templates-&gt;setTemplateMode(TemplateMode::Site);

// ...

craft()-&gt;templates-&gt;setTemplateMode($oldMode);
</code></pre>

CC BY-SA 3.0
2016-03-29T19:04:47.633Z
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
CC BY-SA 3.0
2016-03-29T19:07:58.500Z
@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
CC BY-SA 3.0
2016-03-29T19:19:09.450Z
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
CC BY-SA 3.0
2016-03-29T21:32:26.740Z
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
CC BY-SA 3.0
2016-03-29T22:03:51.373Z
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
CC BY-SA 3.0
2016-03-29T22:07:48.347Z
@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
CC BY-SA 3.0
2016-03-29T22:09:48.717Z
Oh... duh. I didn't realize that those hadn't been in TemplatesService all along. Cool.
Michael Rog
CC BY-SA 3.0
2016-03-29T19:01:22.320Z
2016-03-29T21:07:36.970Z
2016-03-29T21:07:36.970Z
Brandon Kelly
<p>After updating to <a href="https://craftcms.com/changelog#build2778" rel="noreferrer">Craft 2.6.2778</a>, my plugin is causing these deprecation errors:</p>
<blockquote>
<p>PathService::getTemplatesPath() has been deprecated. Use TemplatesService::getTemplatesPath() or TemplatesService::getTemplateMode() instead.</p>
<p>PathService::setTemplatesPath() has been deprecated. Use TemplatesService::setTemplatesPath() or TemplatesService::setTemplateMode() instead.</p>
</blockquote>
<p>How do I fix these?</p>

<plugin-development>
How do I fix getTemplatesPath() / setTemplatesPath() deprecation errors?
# How do I fix getTemplatesPath() / setTemplatesPath() deprecation errors?

(Asked by: username_0 on 2016-03-29)

After updating to [Craft 2.6.2778](https://craftcms.com/changelog#build2778), 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?

**Tags:** plugin-development

---

## 2 answers

### Answer by username_0 on 2016-03-29. Score: 6 | Accepted answer

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);

> **Comments:**
> **username_1**: 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.  
> **username_0**: @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.  
> **username_1**: 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.  
> **username_2**: 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. :(  
> **username_3**: 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()`?  
> **username_0**: @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.  
> **username_3**: Oh... duh. I didn't realize that those hadn't been in TemplatesService all along. Cool.  

---

### Answer by username_1 on 2016-03-29. Score: 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:

Do nothing and have it spew “alarming” deprecation errors to
admin when running Craft 2.6.2778 or later.
Update it to the new code, and say your plugin requires 2.6.2778
(and have it break on all previous versions of Craft).
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.


---

