Got exception:
Fatal error: require_once(): Failed opening required '/usr/share/nginx/www//usr/share/nginx/shared/files/mailsystem/HTMLMailSystem__SmtpMailSystem.mail.inc' (include_path='.:/usr/share/php:/usr/share/pear') in /usr/share/nginx/www/includes/bootstrap.inc on line 3046 Call Stack: 0.0005 337816 1. {main}() /usr/share/nginx/www/index.php:0 0.0575 874476 2. drupal_bootstrap() /usr/share/nginx/www/index.php:20 0.3157 5913664 3. _drupal_bootstrap_full() /usr/share/nginx/www/includes/bootstrap.inc:2164 1.6022 34632696 4. module_invoke_all() /usr/share/nginx/www/includes/common.inc:5021 1.6865 35623620 5. call_user_func_array() /usr/share/nginx/www/includes/module.inc:819 1.6865 35623812 6. mailsystem_init() /usr/share/nginx/www/includes/module.inc:0 1.6865 35623812 7. mailsystem_get_classes() /usr/share/nginx/www/sites/all/modules/mailsystem/mailsystem.module:17 1.7163 35995128 8. class_exists() /usr/share/nginx/www/sites/all/modules/mailsystem/mailsystem.module:306 1.7163 35995448 9. drupal_autoload_class() /usr/share/nginx/www/includes/bootstrap.inc:0 1.7163 35995524 10. _registry_check_code() /usr/share/nginx/www/includes/bootstrap.inc:2970

It's pretty bad, I though uninstalling and reinstalling would help, but in troubleshooting I deleted the mailsystem directory in my files directory and now get WSOD. Any idea how this screwed up path got created?

Comments

This is the MAIL inc file path issue. Just try to do these 2 steps:
1. Special the file path on mailsysytem.module.
// Build the class filename.
$class_file = drupal_realpath($class_dir) . DIRECTORY_SEPARATOR . "$class_name.mail.inc";

Change it like to:
$class_file = str_replace('public:/', variable_get('file_public_path'), $class_dir) . DIRECTORY_SEPARATOR . "$class_name.mail.inc";
Just example, you just need change the realpath for the inc file.

2. Clear older data for the mail inc file recorder.

<?php
db_query
("DELETE FROM {registry}");
db_query("DELETE FROM {registry_file}");
registry_rebuild();
?>

I'm worded on mailsystem-7.x-2.28 and htmlmail-7.x-2.60.
Detail solution guide in here: http://drupal.org/node/1140052.

Patch?

Tried following the steps from #1 - but got the same error. This happens after submitting the mailsystem settings form with create a new class options HTMLMailSystem format() and SmtpMailSystem mail() methods selected.

Step 2 did help restore the site. BTW another way to restore the site is with a symlink in the drupal root directory pointing to the highest parent directory of drupal (in my case '/usr' which appears in the error message after the double directory-separator characters // )

Version:7.x-2.34» 7.x-2.x-dev
Status:Active» Needs review
StatusFileSize
new1.6 KB

This happens, at least in our case, whenever files is a symlink to another location.

This patch uses variable_get to build the file path. It tries to use the private filesystem first, as it seems a better place for code. Not sure if that is a good choice and I haven't tried the patch within a installation with private files enabled, though.

StatusFileSize
new1.58 KB

* fixed the indentation (tab)

StatusFileSize
new1.67 KB

Patch in #5 caused fatal errors : 'Only variables can be passed by reference' in the file_prepare_directory function calls.

updated patch attached.

Status:Needs review» Needs work

I was unable to apply the patches in #6 or #5. I am on Mac OS X using MAMP.

I tried applying the patch like this:
patch -p1 ../../../patches/mailsystem.1534706.6.patch

but it simply hung and I had to cancel it manually.

I then just opened up the patch and made the changes manually in Vim. However, when I did this and attempted to create a new class with the module (on the mail system settings page, create a new class with format() MimeMail and mail() defaultMail), I got the following error:
The specified file temporary://filef5qHuB could not be copied, because the destination directory is not properly configured. This may be caused by a problem with file or directory permissions. More information is available in the system log.

In the system log, the following other entries are present:
Message Notice: Undefined variable: class_file in mailsystem_create_class() (line 151 of /srv/bindings/ca3676e8f9774d40abd26af71993903a/code/sites/all/modules/contrib/mailsystem/mailsystem.module).
Message Notice: Undefined variable: drupal_root in mailsystem_create_class() (line 151 of /srv/bindings/ca3676e8f9774d40abd26af71993903a/code/sites/all/modules/contrib/mailsystem/mailsystem.module).

I don't know how to debug this further but I'd like to report that it didn't work for me.

I'm using the latest 2.x-dev version (2012-Apr-11) of mailsystem as well as Drupal 7.18.

I was able to get it working using a custom module and the solution described here:
http://drupal.org/node/1369736#comment-5644064

StatusFileSize
new605 bytes

I have a site running on Acquia's dev cloud and hit this problem. Being that the files directory is symlinked I believe this is causing the require_once to fail. This basically took down the entire site and required a restore.

Using the technique described in #8 worked for me on the dev cloud. I've attached the small module I created to make this happen as an example.

Hope this helps.

Thanks.

Nick

Status:Needs work» Needs review

Hi there,

Pach in #6 applies cleanly to both dev and 7.x-2.34 releases. The command to apply the patch is:

patch -p1 < path/to/patch/mailsystem.1534706.6.patch

It should be invoked from mailsystem directory (usually sites/all/modules/contrib/mailsystem)

It looks fine to me but I have no easy way to test it right now.

Sorry for my patch in #4. After fixing our problem, I kind of rewrote the solution and posted it without actually testing it. My bad. However, I can say the idea behind it works just fine. We are using it right now.

On the other hand, I would say a solution to #1369736: Alternative locations for "created" Class files? would be probably better than using the filesystem. I don't think this two issues should be considered duplicate, but they address the same problem.

I've also ran into this problem - thankfully after several hours of tweaking and searching found this thread!
The patch in #6 works for me too with 7.x-2.34.

Tested on a dev and staging site with Acquia Cloud and seems to work perfectly. Thanks!

Not sure if this would help issues like this, but figured might as well pose the question: how feasible would it be to have classes/files generated by this module be managed by the features module and exported to module code?

Issue summary:View changes

#6 worked for me as well. Can this be committed? I spent hours trying to fix this issue.