vwal

This is probably too late for the OP, but in case someone finds this through search, I’ll add here the following note.

In order for the plugin to confirm, the sender email must be validated via the AWS SES console. I needed to get this working, and had to read through the plugin code until this occurred to me. The validity of the credentials is tied to whether at least one confirmed sender email address is found. The email address entered in the plugin config in the “Sender Email” field must then match an address that has been validated through the AWS SES console.

The plugin’s status message “Sender Email is set” only implies that an address has been entered in the “Sender Email” field; it does not know whether you have verified an address through the AWS SES console.

Maybe this wasn’t an issue for the OP, but it tripped me up for some time, so maybe this comment will save someone time down the line.

NOW it’s working as far as I can tell! ?? Backslashes and empty lines are now correctly preserved. Well done!

The “$” preceded by a “\” still look different, but that’s no biggie; the main thing is that all the characters are displayed.

Thanks for fixing this!

It’s getting better! ??

With 2009.0.1.26 the newlines in the post bodies are left intact, and the backslashes in the code are preserved.

The only problem that I see now is that all the empty lines in the code are removed and placed in the end of the code segment (so that spacing in code is gone and there are the corresponding number of empty lines in the end of the code block).

I reverted my blog back to 2009.0.1.23 once more, but you can use my original code block to test. ??

Ah, I spoke too soon. While the problem with backslashes has been fixed in 2009.0.1.24, when active, the plugin now removes newlines/linefeeds from all posts on the blog whether the posts have code segments in them or not! When viewed in the editor, the paragraphs in the posts show up correctly, but on the display side all text runs together without any line/paragraph breaks, whether or not the specific page contains code tags or not.

Going back to 2009.0.1.23 fixed that problem, but obviously the backslash issue then remains.

All right! I just upgraded to 2009.0.1.24 and now all characters are being displayed without having to escape them! Many thanks for fixing this!

Cosmetically, the first “$” after the backslash still looks different than the “$” that follows (take a look at the problematic line on my example page; it’s as if the first “$” is in boldface while the next one is regular). But this is not significant; the main thing is that all the characters are displayed and that’s working well now! ??

Hi,

I just updated to 2009.0.1.23… and the problem appears to persist. I have to enter..

eval “local fspath=\\$${fsname}path”

in the HTML view for it to display:

eval “local fspath=\$${fsname}path”

..in the blog. I also tried to edit it in the visual editor, but entering “\$$” produces just two dollar signs (and no preceding backslash) when saved. With “\\$$” a backslash followed by dollar signs is displayed, but the first dollar sign looks different (escaped?), so for consistent look I put “\\\$\$” which then shows up as “\$$” with both dollar signs looking alike.

Language type is bash.

I also see similar problems with bash script (or technically Bourne shell script..) on WP 2.8.2 with nothing but Developer Formatter and Akismet plugins active. I’m currently using Fusion theme, but changing to the WP default theme makes no difference.

A good example is here. A reader pointed out there was a problem with the script I had posted with Developer Formatter. It turns out Developer Formatter was not displaying a backslash in front of a dollar sign; it was apparently being treated as an escape character instead. Adding a second backslash in the code (to escape the backslash) produced one backslash in the display. You can download a tarball of the script I posted on my blog from the page I linked above if you want to test locally how Developer Formatter displays it.