Template files do not work when using admin theme

clear the cache

Too bad, for a second I was hoping that this would fix it. But no, still no luck.
I'm using the following modules:

auto_nodetitle
cck
date
filefield
front
i18n
imageapi
imagecache
imagefield
languageicons
lightbox2
markdown
mimemail
pathauto
simplemenu
simplenews
token
transliteration
views
webform
xmlsitemap

Could one of these modules be the problem?

Having the same problem here. Tried clearing the cache. I then suspected it might have to do with the Zen theme so I upgraded to the latest version of it as I noticed they had made changes to their theme registry code. I tried simplenews-newsletter-body.tpl.php and the more specific template with the term id, both with no luck. Upgraded to the dev version of simplenews. Even tried using a preprocess function in my template.php to override the body variable.

The only solution that worked for me was to drop my override directly into the preprocess function of the module. Not pretty but it works for now.

Any ideas would be appreciated. Other than this problem simplenews has been working really well.

Had the same problem. Updating Drupal and Simplenews to the latest versions did the trick...

Robert

I did as well, still not working.
Also the title override is not working.

This should be working, isn't it?

I got stuck with the same issue. When sending my test mails, templates are working fine. As a last step, I tried sending the newsletter in de develop-environment to the complete list (with cron) and... no template was applied. After that, I tried sending without cron. This works like a charm.

@bariswanschers: This overide should be working, and is working in my setup, though without cron.

I found another post with template-issues in combination with cron: #364301: Cron does not use template files.
Maybe that will help?

Duplicate of #364301: Cron does not use template files.

Hi guys,

I'm not talking about errors while using the cronjobs. Even with test messages, no templates are being used.
Only the mail.css is added by Mimemail, but neither one of the template files is being used as well as the title override.

Any ideas?

You probably experience the same problem when creating other template overrides (e.g. Views). At lease I do and I have not found a solution other than clearing cache and using the rebuild registry function of Zen theme (which clears the registry cache on each page load). This is a core thing and is by design. If you want to continue this discussion please use the issue in #4.

I have the same problem.
Using latest versions of Drupal 6, Simplenews and mimemail and the templates in my theme directory are simply being ignored. I'm not using Zen and all other custom templates are working fine, just simplenews ones that aren't.

I have the same problem as #10, subscribing.

I can confirm this issue too. I have latest version of Drupal, simplenews, and mimemail.

What I have discovered is that simplenews IS using the tpl files in the module directory but ignoring the ones in my theme directory when I copy them there....and yes I have cleared the cache to rebuild the theme registry.

Im not sure what it is that forces Drupal to use the version of the tpl file in the theme instead of the one if the module but obviously this functionality is broken.

or it could be something completely different, but that's why we love drupal :)

Any updates so far? It is still not working with the latest release..

This is the function I have in template.php, to remove the taxonomy-tag:

Where looks is the name of my template. phptemplate_simplenems_newsletter_subject() doesn't work as well.

- I cleared the cache
- I re-actived my template.

Still nothing. And my issues regarding the usage of the .tpl files (eg simplenews-newsletter-body.tpl.php) still stands. They are not being called at all.

Please help, I really need this to work soon!

Not a duplicate, please look into it

I can confirm this problem. Neither clearing the cache nor using drupal_rebuild_theme_registry() helps.

*kick*

Another suggestion is to truncate the cache* tables (clear the table contents, not delete the tables). This is the most fundamental way to clear all caches.

Come on guys, does nobody knows how to solve this?
I issued this 2 months ago and still no fix. I wsh I knew how to fix this myself, but I don't.

Please help, I really need this to finish my project..

I had issues with cron, and this was solved by adding the template files to the admin-theme. Maybe this will help?

The same problem.
simplenews-newsletter-footer.tpl.php is working.
simplenews-newsletter-body.tpl.php doesn't
All those files are in theme dir.

The same problem, but it's works for me when administration theme is not used for content editing (Use administration theme for content editing has to be unchecked). Drupal (or Simplenews module) is looking for the template files in the directory of the actual theme and it's in that time Administration theme.

[subscribing]

Hmmm, that could be the issue. I have Garland as the Admin interface, also for content editing and my own template for the design. I don't like to edit the Garland theme however, isn't this just a bug in the module?

Under Site Configuration > Administration Theme, I unchecked the box for "Use administration theme for content editing" and the template file didn't appear.

Then I went back and selected my theme instead of Garland as the Administration Theme. I sent the simplenews newsletter and my template file worked!

Thanks for the tips!

Katie

ok but is there a way to use administration theme for content editing (ie. garland) AND have the simplenews templates in my custom theme at the same time ?

Exactly. An HTML newsletter should use the site's theme, NOT the admin theme. After all, who is the newsletter going to ... editors? No, it's going to the site's customers.

I'm about to develop a template for a Simplenews newsletter. If I find that it won't use the template in the site theme directory, I will hack Simplenews to get it to look in the proper directory, and report back here, unless, of course, a bug fix is issued before that.

Ha, turned out the newsletter design I received has its own layout, and doesn't need to inherit any theme elements from the site theme, so no need to worry about which theme folder the newsletter body/footer templates go into. I put them in admin theme folder and they work fine.

Still, it's good to know that newsletter templates should go into the admin theme folder. Once I did that, worked like a charm!

yeah i figured this out myself a while back.

Should we put forth the effort to make simplenews look the the "default" themes directory for the template?

It would be easier in terms of keeping templates organized, for sure. Not sure how it helps in terms of consistency of theming, given you probably want to theme a newsletter as self-standing HTML (no css or js or meta, etc) even when you do want it to look like the rest of the site.

@ccshannon

Thats a good point. Maybe newsletter templates should be kept in a separate location? This would make it easy to have multiple templates. If newsletter templates could be setup like themes it would be a double bonus.
Possibly in a location like sites/all/newstemplates or something. Using ".info" files to store the template information. I would love to expand on this idea.

Pros:
Templates would be easily maintainable and shareable when not mixed with the theme files.
Much easier to have multiple themes.

Cons:
Many code changes. Lots of patches.
possibly more difficult when you only need one template ever? is this common?

I have a multiple use-cases for something like this and would love to get my hands dirty and help get to a solution.

----------

I have tried the 6.x port of simplenews_template to solve this issue a while back, but it didnt work as expected. I thought templates would be file based but they were not.
#243567: New Drupal 6 release of Simplenews Template

I can confirm it is also not working for me with the following configuration:

* D6.13
* Simplenews rc6
* Mimemail is disabled
* simplenews-newsletter-body.tpl.php customized and placed in the front-end theme
* Admin theme is Garland
* Preview works just fine
* Cron send uses the default template from the module folder

I suspect that this is a core bug since simplenews isn't doing any crazy theme hacks that I could find, but this is reported here because most modules don't use theme info during the cron.

At the moment, the best workaround appears to be pasting your custom template back in to your simplenews folder and overwriting the default file.

in reply to #30 and #31

I've made a very quick and very dirty hack to make this possible. It might completely destroy other functionality but if you only use HTML mail (MIME mail module) for SimpleNews, this hack is very effective!

Put your entire html (html tag, head tag, body tag, css, ... everything!) in simplenews-newsletter-body.tpl.php. Omit the body and html end tags and put them at the bottom of simplenews-newsletter-footer.tpl.php.

the body tpl should look like this:

And the footer.tpl should look like this:

Then open up modules/mimemail/mimemail.module and comment out line 120:
//  $body = theme('mimemail_message', $body, $mailkey);

This will make Drupal skip the entire theming proces of the node.

The result is that the content of your node will get parsed and replaced and so on, but Drupal will not theme the node as a page. Instead it will be outputted as is. And that's very good if you put the full HTML in the template.

This is a quick and dirty hack and might very well break other functionality! Use at your own risk.

+1 for not working with Simplenews and Views tpl overrides.

Note: for views in my case i was able to place the tpl file in both the admin theme and the desired theme. This worked. It just shouldnt be necessary sense any added tpl file to the admin theme could be accidentally removed with a module update.

This issue is blocking the stable release of Simplenews. I need your input to find the *cause* of this problem.
In the attachment you find two patches. One to theme.inc and one to simplenews.module and simplenews.admin.inc.

theme.cron_theme.patch:
This is a debug function to verify the theorie that during cron execution the wrong theme is selected. This theory can not be confirmed from the code.

simplenews.cron_theme.patch:
This patch temporarily adds an option to admin/settings/simplenews/mail with which a cron theme can be selected.

Test plan:
1. On a test site, you create a simplenews newsletter issue. Configure simpelnews to send using cron. Save and send the newsletter, but do NOT execute cron yet.
2. Patch theme.inc with theme.cron_theme.patch.
3. Fire cron. Make sure you do not load any test website page.
4. Remove the patch or uncomment the code.
5. Check the watchdog content. It should contain one message "$theme_key set to: ". According to the theory the listed theme is the admin theme (e.g. garland). It should however be the default theme.

6. Create a newsletter template simplenews-newsletter-body.tpl.php in your site custom template. Make sure it differentiates clearly for the default template.
7. Clear the theme registry (or all caches).
8. Apply the second patch (simplenews.cron_theme.patch).
9. Select your site theme at admin/settings/simplenews/mail.
10. Create a new newsletter issue and save and send it but do NOT fire cron.
11. Reactivate the first patch (theme.cron_theme.patch).
12. Run cron.
13. De-activate the first patch.
14. Check the content of the watchdog and the newsletter format. The watchdog should list your sites theme, the newsletter should be formatted by the new template.

If you can not patch you can still contribute. Send me a PM with the login details (ftp & site admin) to enable me to test on your test-server.

Attachment	Size
simplenews.374222.zip	2.62 KB

Subscribing

We don't need supporters, we need testers!

I've tested the patches. Im using Garland and a home made theme.

The results:
5) $theme_key set to: garland
9) Home made theme selected in new Cron drop down
14) $theme_key set to: home made
14) Newsletter is NOT using home made theme simplenews-newsletter-body.tpl.php

So this theory seems to be invalid. Is there anyone who want to give me give me full access to a test site to debug this problem?

Sorry Sutharsan, Ive just discovered that the installation I was testing on (a public site) had an old hacked version of the Simplenews Template module semi installed and that it caused the templates to behave iradically. So the test results I published is'nt valid.

I will try to make time to do the test again as soon as possible.

Sutharsan> we've got this problem too, I'll look into it to see if I have a test site where you could take a look.

@Sutharsan

I have the same Problem with the Simplenews and the Admin Module. I set the admin theme setting under admin/themes/admin to default, but choose to switch to the admin theme when editing nodes. When i send out test newsletter (not over cron) my custom theme is _not_ used, but it's used when i send over cron - unfortunately even cron seams to render the nodes as a logged in user is available, which adds some of the Admin module's overlays in the newsletter. I even tried your patches and got...

$theme_key set to: raumboerse

.. when sending over cron, which seams to prove that my custom theme is used.

If I can, I would be very happy to help.

Thanks,
Moritz

I was able to reproduce this bug on my Windows laptop (running Acquia Drupal Stack and Eclipse) as follows:

1. Install Drupal 6.14
2. Install Simplenews 6.x-1.x-dev
3. Copied Bluemarine core theme to custom theme located in /sites/all/themes/snewstest and set copied theme as default theme
4. Copied simplenews-newsletter-body.tpl from SN module to custom theme directory, and edited the heading as follows: <h2><?php print "NOT " . $title; ?></h2>.
5. Created newsletter with subject of “SN Test” and body of “BROKEN”.
6. Added my email as subscriber
7. Set Administration Theme to Bluemarine and checked “Use administration theme for content editing”
8. Bug was reproduced, as email body contained “BROKEN” rather than “NOT BROKEN” This was observed for both Test and Cron runs, in both plain and HTML format.

I traced the code and believe the problem is caused by the system setting the theme to the Administration Theme while in the node editing form from which the “Send Newsletter” functionality is found (cron runs must invoke the Admin theme as well).

This automatic setting of the admin theme occurs in system.module line 535:
global $custom_theme;
$custom_theme = variable_get('admin_theme', '0');

I was able to work around this behavior by inserting the following lines of code into simplenews.module at line 1516 (after if (!isset($messages[$nid][$langcode]))

global $custom_theme;
$save_theme = $custom_theme;
$custom_theme = NULL;

And at line 1561 (at end of if block):
$custom_theme = $save_theme;

Although this seems to fix the problem, after tracing the theme code, I am concerned that this approach may cause some other unforeseen problem, due to the complexity of the Drupal theme system, and the fact that I am changing global variables usually set by Drupal core. Could someone please test this code, by either modifying your simplenews.module as described above, or applying the attached patch. Hopefully this will fix this issue for now. In the future, I think the idea in #31 above, whereby Simplenews templates would be located in a separate directory, e.g. /sites/all/newstemplates, and made independent of any specific theme, should be given serious consideration.

Thanks!

Attachment	Size
patch.txt	1.6 KB

Unfortunately, forcing the use of the front-end theme will break any sites relying on the emails to be sent via the admin theme. Although they *shouldn't* be doing that, some will because of this bug.

A better solution would be to add a SimpleNews setting that lets you choose whether to use the front-end or admin theme, defaulting to the front-end for installs but updating to admin for existing sites. Then, no existing sites should break.

Even that is really still a workaround. The best solution involves fixing it in core, but that's unlikely to happen until at least D8 now.

Re #44: but these lines in system.module are only executed on node add/edit forms and admin/* urls. How does this affect the theme when printing?

re: #47

I don't understand why we need to support having templates in the admin theme going forward. Putting templates in the admin theme was only a work around for a bug - they never should have been there in the first place - and Simplenews should not have to support their being there in the future.

Essentially, it is a bad practice to keep templates in the admin theme (as the admin theme is usually a core Drupal theme) and having an option to do so might encourage this bad practice. Rather, any templates in the admin theme should be immediately moved to a front-end theme as soon as the Simplenews template override bug is fixed.

When the bug is fixed, we should communicate that templates must be moved to the front-end theme by posting warnings on the Simplenews Project page, Handbook pages, and README.txt. That way the only users negatively effected would be those that have templates in their admin theme and neglected to read the instructions - which I would think would be very few.

re: #48

I don't understand what you meant by printing?

I tested the patch successfully with sending a test email, sending newsletter without cron, and sending with cron, for both plain and HTML newsletters. Is there an option to print somewhere that I am not aware of? Does this also require the use of the templates?

It's pretty easy here to avoid breaking backward compatibility, so I think we should. No matter how diligent we are about documenting the change, it's going to break some sites if we don't maintain backward compatibility. It doesn't help that it's a pain to test, and sometimes there is more involved than just copying templates.

We don't have to support it for long, and can / should specifically say that it's temporary and admins should change it. The whole issue should be temporary, really, since it needs to be handled in core at some point.

Re: #48 - It changes the theme, sends the email, and then immediately changes it back. Only actions that happen during the email send would try to use the altered theme, unless the state gets hosed by the theme change.

System.module changes the theme during hook_init but that may not have to be true here. I can't tell if there will be other consequences.

re: 51

Would you be willing to create a patch for this?

You would have to auto-detect if Simplenews templates exist in the admin theme at install time, and have a setting like "Override Template Location" set to either "Admin Theme" (templates exist) or "Default Theme". And I am not sure how to handle the situation where Simplenews templates are found in both the admin and default theme?

I assume the ui for the setting would be located on /admin/settings/simplenews/general?

You would also need to document the setting, communicating that having templates in the admin theme is only a temporary feature due to a prior bug that is now fixed. And the setting would have to be tested for combination of: templates in admin theme, templates in default theme, cron/no cron, plain/HTML, and send test newsletter.

My concern is that due to the increased complexity of having this temporary feature, that a bug could result, creating more pain for the user than if he had been forced to move his themes to the default theme directory in the first place. And, the bug could effect all users, not just ones with templates in the admin theme. And, even if all of this is implemented bug free, none of the work benefits the project going forward as it is only a temporary feature that will have to be removed from the code and documentation in a future release.

I can create a patch if it comes down to it, but I'm also working on a ton of other patches. :)

We don't actually need any template detection logic. Using a .install update hook, it can be set appropriately for upgrading users and differently by default. The setting is really just "yes, do the workaround" or not. If it is set, then it uses the new code added by your patch. If not, don't change the theme at all there.

Really only the "yes, do the workaround" option has to be fully supported. The goal is to give the site admin time to fix it the right way (and to notice that it's a problem).

There is also a hook to display a note on the site status report, which could say it's using a deprecated setting. Or if you don't want to maintain backward compatibility, then you could also just implement that hook and check the admin theme for a simplenews template. That's still better than no in-site warning at all.

I'm not worried about difficulties removing the code later, since it will be fairly isolated.

Why don't we let Sutharsan decide if he wants to wait on your patch which would provide backwards compatibility or implement my patch which would force upgrading users to move their templates.

Ok, I followed captaindav's description and was able to reproduce the problem (pew, at last!). The theme which is going to be used is determined in init_theme() in this code

Core sets $custom_theme to the admin theme as per "Administration theme" settings. Because the email is sent while the admin theme is the current theme the email is formatted using the admin theme. So the problem only occurs if the emails are sent 1. upon saving the node (no cron) and 2. when the admin theme is not the default theme. We could or force the use of cron, forbit the use of admin theme or set the theme as in #44. You choose ;)

Captiaindev's code should be extended with a simplenews admin option to select the theme. Which is by default the site's default theme.

Backwards compatibility is not an issue. We put some code in to detect the situation and give an error on the Status report page.

@captaindev: I meant 'mailing' not 'printing'. Many thanks for your push to get this moving again.

Sutha,

Are you sure it works on the cron even with the admin theme set? That wasn't my experience, but I could be wrong.

The only difference between my suggestion and the extension proposed in #56 is an update function. It sets sites that were already using simplenews prior to the fix to use the admin theme (which gives an easy upgrade path, nothing breaks). Fresh installs should still default to the front-end theme.

If simplenews has been installed fresh, the install can set the setting to the default theme. On update, if the setting does exist at all then make it admin.

I set $custom_theme to the theme I want to theme the newsletters with and all looks Ok. But it is subject to crowd source testing.
I don't want to treat the sites with a work-around differently. There can be two kinds of work arounds: those with a custom template in the module directory and those with custom template in the admin theme. It is not simplenews's task to watch over peoples work-arounds.

Attached a slightly altered patch for test.

Attachment	Size
simplenews.374222_1.patch	1.57 KB

Looks like there are some whitespace issues, but nothing else jumps out at me.

patch applies fine against latest -dev, but the 2 tpl.php files in my frontend theme still aren't being used.
When I copy them back over the simplenews defaults in the module folder, everything is fine.

all caches, theme registries etc.etc. were cleared of course.
I am using a 3 themes here: one for the frontend (which is default) one admin theme, and one mobile theme.

note: I'm only testing this now with the 'send one email to the email-adres below'-function.

re: #59

I would name the variable orig_custom_theme rather than org_cutom_theme

re: #59

When I checked out 6.x-1.0-rc6 from CVS, simplenews.module has the following version:

1.76.2.129 (this also agrees with the 6.x-1.0-rc6 tar file version)

However, the patch references this version:

1.76.2.136

Does this matter?

re: #61

askibinski,

With 3 themes enabled, the patch worked on 6.x-1.0-rc6.

Could you try patching 6.x-1.0-rc6 instead of dev?

Thanks,

captaindav

@captaindev: patches are always against the last version in the branch (i.e. -dev)

askibinski gave me access to the site he had the problem with. It is caused by 'slate' which is the admin theme of the Admin module. It handles the admin theme override differently; as a comment in the code says: "Bypass the theme system entirely so we can load our own theme into place." I see no easy solution for this case. For now I like to go forward with the #59 solution and leave the Admin module case as won't fix.

Patch in #59 is now committed to HEAD and 6.x-1.x-dev.
Thanks to all who participated.