vycwebmaster

Ok so I think based on my final results that this looks to be a WP_MAIL BUG

IMHO, WP_MAIL is INCORRECTLY adding the PHP Priority HEADER statement BEFORE the MIME-VERSION: 1.0 statement

This is only an issue if you want to add an attachment … if both an attachment and high Priority are combined, the ATTACHMENT is left in BASE 64 by the Client.

Results:
The removal of the \r\n resolves the issue caused by the extra blank line … this allows for the Priority Flag to be set

HOWEVER

Regardless of the order I add the “HEADER” values in PHP, WP_MAIL is NOT changing the actual RAW header order … “From before Priority” OR “From after Priority” makes no difference to the actual order of Header Statements WP_MAIL is generating

Further, on closer observation, it appears WP_MAILS is filtering out one of the Priority Methods

The only method that was found in the resulting Email is X-MS Mail-Priority: High I had noticed this before, but because I had been using one method for some of my tests had overlooked this detail

I tried to override the WP_MAIL header order by explicitly adding MIME-Version: 1.0 before the Priority statement but appears the Mime Line was filtered out (ignored)

From my perspective, WP_MAIL has the following bug

1) If you attempt to include BOTH an Attachment AND a Priority setting
a) the Priority Flag will be set properly
BUT
b) the Attachment will be left in BASE 64 format

Understand that moving the raw Priority line physically below the the last header line provides the required result of both the Priority flag being set as well as the attachment being converted from BASE 64

2) If I only include the Attachment with a Low Priority the Attachment BASE 64 is converted

Based on my results, it is my position that WP_MAIL is placing the Priority Header statement in the WRONG location within the physical email Header … the Priority statement NEEDS to be the last statement in the header

Back in the mid-90s when I first made the AIX eml scripts, there were actually 3 methods available for flagging High Priority … one of those 3 is no longer supported/recognized … these remaining 2 methods are based on my testing, is still needed for some legacy Clients … don’t recollect which of these two methods is common and which is legacy but have included both just to be certain
X-MS Mail-Priority: High
X-Priority: 1 (Highest}

Appreciate the thoughts on the Base 64 … Considering that I only have to move the position of the 2 Priority Statements and delete a blank line (which then works properly using Sendmail) suggests that the Base 64 content/format/information is not contributing to this issue.

Thanks, I will remove the \r\n and (Highest) and let you know if that has any effect … my test results point to position … but perhaps this \r\n is where the blank line is being introduced

Thanks for pointing out that error in my posting
Here is the actual code that is being used in my PHP process

 // send mail
  $sent = wp_mail($eml_to, $eml_subject, $eml_body, $eml_hdr, $eml_attachments);
  if ( $sent) {
   $eml_status = "Sent";
  }

Based on my test results and history with Sendmail (in AIX), the problem described here is specific to the order that header components are assembled … my test contained all of the header content, but because the Client Software wasn’t expecting the order in which the content was provided it didn’t set the Priority Flag OR convert the Base 64 attachment

In AIX, my eml script did the header pre-assembly in this specific order so the client software would work seamlessly … AIX mail was intended as a text-based admin/root notification tool, it didn’t have any notion of attachments, base 64, Priority, PDF, etc, I researched the email protocol in order to determine how to attach Enterprise DB Reports in PDF format through the available Sendmail process

These days, all of this “PROTOCOL” detail is hidden from view, but, from what I have seen, and especially with this particular situation, the EMAIL process hasn’t changed much since the 1990s when it became mainstream

WP, in this particular case, is running in a UNIX environment, so may ultimately still be using Sendmail at the end of its processing … somewhere in this process it still has to take the Parameters being provided and build/assemble the data following EMAIL protocol guidelines

Functions like WP_MAIL are intended to simplify complex processes … but … in this situation, it isn’t working … is that because I am not providing the header parameters correctly … or … am I possibly not using the function in a way it was intended … or … is there possibly a bug in WP_MAIL

Given:
– WP_MAIL IS sending ALL of the intended HEADER content
– manually reordering that header content and removing one blank line corrects this issue
– it isn’t clear how to provide the header content to WP_MAIL to ensure it is assembled in the order that works (header code is in my first post)

Ok so taking this raw data along with sendmail I determined there are 2 issues with this raw data:
1) line 08 white space affects the Client’s ability to process the raw details
2) the position of line 09 needs to be AFTER the mime declaration

Removal of line 08 and moving line 09 after line 12 and this raw data interfaces properly with the Client … So back to my initial questions … How do we enforce the appropriate order in the Header statement?

01 To: {eml_to address}
02 Subject: {eml_subject}
03 X-PHP-Script: {some details regarding source location and ip}
04 X-PHP-Originating-Script: 1003:PHPMailer.php
05 Date: {server date and time}
06 From: {eml_from}
07 X-Mailer: PHPMailer 6.5.3 (https://github.com/PHPMailer/PHPMailer)
08
09 X-MS Mail-Priority: High
10 Mime-Version 1.0
11 Content-Type: multipart/mixed;  boundary={unique boundary ID}
12 Content-Transfer-Encoding: 8bit
13
14 This is a multi-part message in MIME format.
15 
16 {unique boundary ID}
17 Content-Type: text/plain; charset=us-ascii
18
19 {body}
20
21 {unique boundary ID}
22 Content-Type: text/xml; name={filename}
23 Content-Transfer-Encoding: base64 
24 Content-Disposition: attachment; filename={filename}
25
26 {base64}
27
28 {unique boundary ID}--

Here is a raw result from WordPress (one that hasn’t been resolved by the Email Client) … from a high level it appears correct … the only difference I see is the order in which headers are being placed.

To: {eml_to address}
Subject: {eml_subject}
X-PHP-Script: {some details regarding source location and ip}
X-PHP-Originating-Script: 1003:PHPMailer.php
Date: {server date and time}
From: {eml_from}
X-Mailer: PHPMailer 6.5.3
(https://github.com/PHPMailer/PHPMailer)

X-MS Mail-Priority: High
Mime-Version 1.0
Content-Type: multipart/mixed;  
 boundary={unique boundary ID}
Content-Transfer-Encoding: 8bit

This is a multi-part message in MIME format.

{unique boundary ID}
Content-Type: text/plain; charset=us-ascii

{body}

{unique boundary ID}
Content-Type: text/xml; name={filename}
Content-Transfer-Encoding: base64 
Content-Disposition: attachment; filename={filename}

{base64}

{unique boundary ID}--

Warning: Potential Roundabout/Outside-The-Box Solution

This Form Plugin provides the ability to have HIDDEN form fields (might be able to also do this with regular HTML fields as they can also be hidden using is embedded jscript on the client-side)

Regardless of the number of times the PHP file is loaded, the key to success here is to capture/save the required data while the HTML is being built, and ultimately have that data available when the submitted Form is processed … as stated impossible using globals as the PHP file that initiates these Globals is being called multiple times … each time the PHP file is run the Globals are reinitiated.

Solution:

1) Client opens a URL (potentially with parameters)

2) WP/Plugin builds HTML page during which time these hidden fields can be populated with required data

3) Client fills out/completes the form and submits the form

4) WP/Plugin is now able to retrieve the previously stored data from the hidden field(s)

Simulate global var(s) by basically using the HTML content to hold the values until required

Thanks for listening … hope this simple idea helps others

Note: the data in these variables doesn’t have to make sense … the more nonsensical the better … using short length codes would be meaningless to most

Thanks for the feedback

I have set up some tests to reveal/prove to myself the actual Client – WP interactions:

Results:
The Plugin provides the ability to add PHP code which hooks into the Form Action and Field Filter processes … these processes run before WP sends the final HTML content to the Client … using a sequence counter initiated to 0 any time the PHP hook file opens, shows that the PHP hooks file is restarted when the Client Submits the form content back to WP

This means the PHP hooks file use of Global variables is problematic … a Global Variable set to capture/maintain URL parameters is lost/reset when the PHP file is restarted.

So brings me back to square one on how best to maintain a “SESSION” related set of vars?

Reviewing the HTML source, the only item that appears to stand out is that the FORM is provided a unique Captcha ID … suspecting this may be generated by some JS on the Client when the Page is loaded because I couldn’t find any reference to this value being generated in WP or the Plugin

From a high level, perhaps it isn’t necessary for WP/Plugin to maintain a link from the HTML page sent to the Client, to the Client’s final submission back to the WP/Plugin

So that begs the question, if I need to tie these connections together, what should I use? I did a search for cookie in WP and the Plugin and see there might be some cookie use … but … if the plugin is using a cookie it wasn’t showing up in the windows app data folder

I could perhaps generate some kind of unique “SESSION ID” on the first connection and create a temporary SQL record but then how would subsequent connections know what record to relate to?

As a top-down dinosaur who has been coding since the mid 70’s, I guess I am having a hard time with this seemingly disjointed process

In a perfect world, I would envision WP creating a unique SESSION ID which it would provide to the Client embedded within the HTML source … any further interaction by the Client would then use this SESSION ID

Patrick,

It appears you have already resolved this issue … however, your example in the documentation doesn’t work … when adding the shortcode to the Passster Options Shortcode, your example suggests that the shortcode must be encapsulated with [passster password=”blah”] [shortcode] [/passster] … this doesn’t work … adding the shortcode by itself and turning on the page password does work … also not following your Dynamic example … {shortcode} doesn’t work at all … Note also that I had to Clear All Cache and reinstall your plugin for this to work … perhaps the residue of some of the tests I did confused your logic.

This has been resolved for what I need … Sorry for the Noise.

Patrick,
ich habe Ihr Produkt erfolgreich für eine andere Website verwendet und m?chte es mit VFB Pro verwenden. Bitte überprüfen Sie dieses Shortcode-Problem und finden Sie eine L?sung.
Vielen Dank für Ihre Zeit

I sent the following question to VFB Pro developer Matthew Muro who replied with the following statement:

My Question:
Just installed the PASSSTER plugin and used it to pass protect a page which has one of your VFB forms … when I go to that page now all I see is the shortcode [vfb id=<id#>] instead of the actual form.

Is this an issue you can resolve OR do I need to raise this question with the PASSSTER people?

Muro’s Reply:

That sounds like something you’d have to ask Passster about. It sounds like they aren’t passing other shortcode output.

You would THINK that the service provider would/should know THIS … AFTER MUCH TO DO IT WAS INDEED A CACHE ISSUE … NOT WP, and NOT the PLUGIN … THIS was a CACHE that needs to be cleared with the CPANEL CACHE MANAGER … is this an OS CACHE … whatever … I have NOW found a working solution with the passster plugin

WP has a page protect option … can’t seem to get that working consistently
AVADA has a page password protect option … can’t seem to get this to work at all
AVADA also has a RESTRICT direct access option … can’t get this to work either
passster once I turned off the Cookie Option in settings now consistently asks for a password for the page I need to be protected.

Case Closed
Thanks for listening … hopefully this may keep others from going down this rabbit hole

New information:

This morning, for ALL scenarios of Menu top-level item focus, the newly added sub-item is now available PLUS the 6 & 7 top-level items are no longer changing places

Highly suggests to me that this is a Server Side Issue most likely CACHED HTML pages … Not sure which of; AVADA, WP, APACHE/Linux, or Other, are responsible for determining when to send out old CACHED HTML pages … the expectation would be that whatever process is responsible for sending an HTML page would do some kind of “dirty” check in order to determine if a new page must be regenerated … there is a lot of noise on CACHE handling but I don’t know enough about what goes on behind the scenes to determine if there is something I can do to force a complete CACHE REFRESH (I installed a plugin called wp-optimize which suggested it does clear CACHED PAGES but running their free functions didn’t solve the issue)… basically my expectation is that if I make a change it should be available NOW not several hours later

Point taken … a new WP function … NOT a wp_delete_post() enhancement

This new function would need to: delete all associated media files and delete all records with the exception of any audit related records (retaining: post_date, post_time and post_id)

My observation of the mangled variable was on the right track … the WordPress Page editor/parser wants to wrap everything you enter in the page editor with HTML “paragraph” tags … WP provides a way to get around this by enclosing
<script> blah </script>
with
<pre> blah </pre>
which tells the parser to use the content raw

Note: tried an HTML raw plugin but it didn’t seem to work using
<raw> blah </raw>
Note also: found that jQuery must be used in place of $ inside a WP Page, which from what I read, should use the “current” jQuery library.

My test code now runs as designed when enclosed with “PRE” tag. … Perhaps WP should include the PRE tag as an option in the HTML(text) view of PAGES?

• This reply was modified 6 years, 2 months ago by vycwebmaster.

This example was coded in the pages editor (Dashboard New Page) … The project is to augment an online membership form built in VFB Pro that requires the ability to have:
1) 1 or more Contact details for both Primary and Secondary Members
dynamic rows of: Member, Contact Type, and Contact Detail
2) 1 or more Interest details for both Primary and Secondary Members
dynamic rows of: Member, Interest Type, and Interest Detail
3) 0 or more Tertiary Members
dynamic rows of: Name, Year of Birth

Primary: Name, YOB, Photo, Profession, Profession Status, Contact(s), Interest(s)
Secondary: Name, YOB, Photo, Profession, Profession Status, Contact(s), Interest(s)
Tertiary: Name(s), YOB(s)