Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Message bodies are always NULL #240

Open
akopciuch opened this issue May 24, 2019 · 5 comments
Open

Message bodies are always NULL #240

akopciuch opened this issue May 24, 2019 · 5 comments

Comments

@akopciuch
Copy link
Contributor

Feature request or bug

Bug

If a bug, what did you expect to happen?

Get the body of an email using
$body = $message->message->text;

If a bug, what happened?

$message->message->text is NULL, but the body clearly exists in the object(s) when debugging (var_dump, print_r, etc.)

If a bug, list steps to reproduce bugs.

Try and access the "text" property on a message.

If a bug, did you do these steps?

[] Download and use the latest stable version
Yes
[] See if the issue has already been reported
Yes, there are similar issues, but they seem focused on base64 decoding.
[] Debug
Yes

If a feature request, what do you want to be added or changed?

If a feature request, is this feature already in a pull request?

If a feature request, do you know anyone who can help?

Side notes(Read then del this chunk)

It seems to come down to a problem in the getBody() method on the IncomingMessage class.
IncomingMessage.php:384

if(!is_object($obj) || !property_exists($obj, 'structure')) {
    continue;
}

Using property_exists on an object of type SubtypeBody which extends Section will never detect a property named "structure". The property on the parent class Section is actually $_structure. "structure" is a special property availble using the __get() method which property_exists will not detect.

This means every message will simply continue to the next section without ever setting a value to $obj->plain. Which in turn means that is never decoded and assigned to $obj->text. The message body properties are simply NULL ... always.

I tried changing it to look for property_exists("_structure"), but the same result occurred. I think it has something to do with the fact the object is actually an extension of Section. I'm not sure when class properties will be detected as existing when inherited from a parent. Especially without having explicit __construct() methods.

I modified my local copy of the code to be like this below, and I instantly could access the email message bodies again.

if(!is_object($obj) || !$obj->__get('structure')) {
    continue;
}

I think that should work, because it looks like the verification is checking to make sue it is actually an object type, and the structure property exists ... which the result of __get() will reflect. Feel free to patch it that way, or if there is a better way to write that code that I'm just not understanding.

@mcki0127
Copy link

I'm having the same issue. Is there a planned fix for this?

@akopciuch
Copy link
Contributor Author

I did a pull request with the fixed code, but It looks like it failed some build somewhere because of PSR formatting ... but that's not in the current master. It's just a bunch of spaces added really. I don't understand at all what's going on there. I did the pull request ... so we'll see where that goes.

@pedrohdsantos3
Copy link

pedrohdsantos3 commented Jul 23, 2019

I have applied akopciuch solution for my local code, but the bug stil here.

Did you made some another change?

@akopciuch
Copy link
Contributor Author

No. It was a single line change on line 384 of the file IncomingMessage.php

if(!is_object($obj) || !property_exists($obj, 'structure')) {

becomes

if(!is_object($obj) || !$obj->__get('structure')) {

@andrewtite
Copy link

PLEASE ADD THIS TO THE COMPOSER.
UPDATED ON MY SITE BUT IF COMPOSER DOES AN UPDATE OR SOMETHING...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants