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?
Comment | File | Size | Author |
---|---|---|---|
#9 | Smtp_Html_Mail.tar_.gz | 605 bytes | nickgs |
#6 | mailsystem.1534706.6.patch | 1.67 KB | tripper54 |
#5 | mailsystem.1534706.5.patch | 1.58 KB | tobiasb |
#4 | mailsystem-fix-class-path-1534706-4.patch | 1.6 KB | esclapes |
Comments
Comment #1
husumiao-1 CreditAttribution: husumiao-1 commentedThis 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.
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.
Comment #2
pillarsdotnet CreditAttribution: pillarsdotnet commentedPatch?
Comment #3
technicalknockout CreditAttribution: technicalknockout commentedTried 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 // )
Comment #4
esclapes CreditAttribution: esclapes commentedThis 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.
Comment #5
tobiasb* fixed the indentation (tab)
Comment #6
tripper54 CreditAttribution: tripper54 commentedPatch in #5 caused fatal errors : 'Only variables can be passed by reference' in the file_prepare_directory function calls.
updated patch attached.
Comment #7
ptmkenny CreditAttribution: ptmkenny commentedI 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.
Comment #8
ptmkenny CreditAttribution: ptmkenny commentedI was able to get it working using a custom module and the solution described here:
http://drupal.org/node/1369736#comment-5644064
Comment #9
nickgs CreditAttribution: nickgs commentedI 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
Comment #10
esclapes CreditAttribution: esclapes commentedHi 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.
Comment #11
mto CreditAttribution: mto commentedI'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!
Comment #12
technicalknockout CreditAttribution: technicalknockout commentedNot 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?
Comment #13
thelocaltourist CreditAttribution: thelocaltourist commented#6 worked for me as well. Can this be committed? I spent hours trying to fix this issue.
Comment #14
JeroenT#6 Worked for me.
Comment #15
jygastaud CreditAttribution: jygastaud commented#6 works for me too.
I had that kind of issue when with phpmailer module/class when combined with memcache.
Comment #16
dxx CreditAttribution: dxx commentedOk for #6.
I use memcache and a relative path for my private folder (like "../prvt/").
I have solved with this patch and edited manually the registry table in db.
Comment #17
iwhitcomb CreditAttribution: iwhitcomb commentedThis is a cool little feature of this module, but I have to ask; is this really the most reliable way of handling this?! Typically the files directory doesn't/shouldn't get version controlled thus the file(s) generated by this module doesn't get transported with the rest of the code base like it needs to. If you're using something like stage_file_proxy like I am, or the file gets deleted for any reason then you're in trouble.
I strongly second #12 -- these generated files belong in a module/feature somewhere, not in the files folder.
Comment #18
samuel.mortensonsubscribe
Comment #19
DrSage CreditAttribution: DrSage commentedTo fix this issue we could update update path to new library by updating path in the registry table.
update registry set filename = 'sites/default/files/mailsystem/MimeMailSystem__DefaultMailSystem.mail.inc' where name='MimeMailSystem__DefaultMailSystem'
And another solution is to use https://www.drupal.org/project/registry_rebuild
Comment #20
rakesh.gectcrfor me
worked
Comment #22
Nafes CreditAttribution: Nafes as a volunteer commentedCommitted. Thanks!
Comment #23
Nafes CreditAttribution: Nafes as a volunteer commentedComment #25
glass.dimly CreditAttribution: glass.dimly commentedI'm running 7x-2.34, and it's not fixed there or in the dev version of this module as of 2017-10-31, on Acquia Cloud where there was some weird absolute file structure for the files directory.
Additionally, the advice offered above did not fix the issue for me.
Registry rebuild did not work because the error was triggered and prevented rebuild.
I found the offending file in the `registry` table and then did this:
And Bob's your uncle.
Comment #26
glass.dimly CreditAttribution: glass.dimly commentedResponding to my comment in #25, the other thing which I did to restore functionality was to move the contents of the file to a .module file in a custom module. Here are the contents of the file: