Mimbo vs. contact form

[yellowled]

For some reason, the Mimbo template seems to have issues with the contact form plugin.

Someone reported to me via email that his installation of mimbo sends an email up to four times when using either the standard or dynamic contact form. This does not happen with a different template, i.e. Bulletproof. I have reproduced this with the standard contact form in my own blog (temporarily switching it to Mimbo), but I can't seem to pinpoint the source of error in the Mimbo .tpl files.

Any ideas?

YL

[garvinhicking]

Hi!

This could be browser related, when a browser posts the data multiple times to the same page, either because maybe there is a misbheaving mod_Rewrite rule, or links to non-existant files or Fasterfox-like plugins.

Does the same happen when you remove config.inc.php?

Regards,
Garvin

[yellowled]

This could be browser related, when a browser posts the data multiple times to the same page, either because maybe there is a misbheaving mod_Rewrite rule, or links to non-existant files or Fasterfox-like plugins.

Even if it only happens with just that template? Remember, it does not happen with BP ...

Does the same happen when you remove config.inc.php?

Yes. I also cleared templates_c after removing it, of course.

YL

[garvinhicking]

Hi!

Did you check the firebug NET extension? This one tells you which URLs are loaded. Maybe then you can spot URLs that are called which have a wrong relative path?

On the other hand, it could be that your template includes the event hook that is called to send the contactform multiple times. It could be that each fetchPrintEntries call executes the event hook that the plugin uses to send the mail...

Regards,
Garvin

[yellowled]

On the other hand, it could be that your template includes the event hook that is called to send the contactform multiple times. It could be that each fetchPrintEntries call executes the event hook that the plugin uses to send the mail...

Since Mimbo makes excessive use of fetchPrintEntries, this sounds far more "promising"

Erm, how do I figure that out, and if so, what can I/we do about it?

YL

[garvinhicking]

Hi!

You could start by checking custom smarty usage in all files. I'd start with fetchprintentries and temporarily remove all occurences of that.

The problem is, if it does affect the call, I think the only way to skip this behavior is to disallow executing hooks throgh useHooks=0 or whatever parameter that was. Then it might influence other features of your template...

Regards,
Garvin

[yellowled]

Just for the record: solved.

Code: Select all

{if $view == 'entry' or $staticpage_pagetitle}

I can't even remember what the " or $staticpage_pagetitle" was supposed to do, but it is the source of error here. Removing it solves the issue and doesn't change the template's behaviour.

YL

[Don Chambers]

ya know, I think that should have been {if $view == 'entry' or $staticpage_pagetitle==''} ?? Whatever! As long as it works, right?!!!

I'm also wondering if the true, front page is always, and reliably, detected with just {if $startpage =='true'}

[yellowled]

I think that should have been {if $view == 'entry' or $staticpage_pagetitle==''} ??

"If view is single entry or a static page which doesn't have a pagetitle"? Doesn't make sense to me.

I'm also wondering if the true, front page is always, and reliably, detected with just {if $startpage =='true'}

I think that wouldn't work at all, but you probably mean {if $view == 'start'}, right? I have no answer for that, but maybe Garvin has

YL

[Don Chambers]

Yes, sorry... got confused for a moment.. thought you were talking about start page detection, not entry pages!

More coffee please.