TinyMCE text conversion issue - tinymce

I am using the TinyMCE 5.8.1 editor against existing data, where the textarea has MIME content:
"MIME-Version: 1.0
Content-Transfer-Encoding: binary
Content-Type: text/html; charset=UTF-8
Dear Steven San, etc etc"
As soon as I call tinyMCE.init the format gets changed, and saving the data the textarea now shows different MIME content:
"MIME-Version: 1.0
Content-Transfer-Encoding: binary
Content-Type: text/plain; charset=UTF-8
Dear Steven San,  etc etc"
All of the HTML formatting seems to be stripped, and the Content-Type changes from text/html to text/plain.
I'm struggling to find anything about this in the TinyMCE documentation, or via google.
How do I stop, or control this apparent stripping of html formatting?
p.s. for new documents, everything is working fine, and storing as text/plain.

Related

How to upload a Salesforce File using REST API properly?

GET /services/data/v47.0/sobjects/ContentVersion/0000v00000MFIVgAAP/VersionData from this request I will get binary file content, but how can I use this content to recreate the file properly (using request to POST /services/data/v47.0/sobjects/ContentVersion)?
I uploaded .docx through the UI and fetch its content.
Then I uploded that content using the request:
Endpoint
/services/data/v47.0/sobjects/ContentVersion
Headers
Content-Type:multipart/form-data; boundary=boundary_string
Accept: application/json
Body
--boundary_string
Content-Disposition: form-data; name="entity_content";
Content-type: application/json
{"PathOnClient":"MyFile.docx"}
--boundary_string
Content-Type: application/octet-stream
Content-Disposition: form-data; name="VersionData"; filename="MyFile.docx"
Binary data from the request to GET /services/data/v47.0/sobjects/ContentVersion/0000v00000MFIVgAAP/VersionData.
--boundary_string--
The request above is executed with a success status code, and the file was created successfully, but when I downloaded this file from UI, it became damaged :(
There may be something in the request body that I missed (but I don’t know what exactly is wrong), so the file creates damaged.

Does Google Schema support quoted-printable encoding?

I'm trying to self-test my email schemas.
My mail is sent with:
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
The original script tag <script type="application/ld+json"> is rendered as <script type=3D"application/ld+json">, when I View Original the marked up email.
This fails the markup tester, but when I manually remove the 3D, it passes the test.
Q1 - Does Google support quoted-printable encoding?
Q2 - Why does the test fail?
Note: On a Rails application I use the Mandrill API to send the email.
1.) Yes, quoted-printable is supported.
2.) You're testing the markup after it had been encoded. You should decode the raw email, then test it.

Fiddler multipart/form-data with auth token asp.net web api 2

I have been struggling with this for few days now, (new to fiddler)
My Url looks like this:
mywebservice/miclaim/casedetail/GetCaseDetail/638110079?apikey=MiClaimUK&token=ZD31MsFiLrFA2hCZShBJ7i4iinqeRxfYNrIsDHWriQM=
Now this is a multipart/form-data content type, and i tried a few things to submit my form data like this: (I have no problem submitting file though.. its just the form data along with file!)
adding the values after the token stuff in the query
LossItemId=1&Description=d&ClaimedAmount=1234.5&WherePurchased=reading&BasisOfValuation=basis&Status=sta
or just adding them on the request header but nothing seems to work, I still don't get my form data values in the controller...
I think it must be fairly obvious and usual thing in fiddler to do, but why am in having so much trouble? What am I missing?
Note: I can test my app by a test client using html form ..enctype="multipart/form-data" method="POST"> and it works... but not in Fiddler??
Had to revisit this problem in my project in the context of some other issue..and finally got it working this time around
(for those who might come across a similar issue):
---------------------------acebdf13572468
Content-Disposition: form-data; name="ToDo"
Content-Type: application/json
{"ToDoId":32,"InstructionId":6300460,"Description":"Description","Comment":"Comment","DueDatetime":"2014-02-28T16:44:52.8140079Z","SubmittedDatetime":"2014-02-28T16:44:52.8140079Z","StatusCode":10,"Media":[{"MediaId":0,"MediaDescription":"abc","CreatedDate":"2014-02-28T16:44:52.815008Z","MediaType":"Doc","UrlPath":null},{"MediaId":0,"MediaDescription":"foo","CreatedDate":"2014-02-28T16:44:52.815008Z","MediaType":"Image","UrlPath":null}]}
---------------------------acebdf13572468
Content-Disposition: form-data; name="fieldNameHere"; filename="abc.txt"
Content-Type: text/plain
<#INCLUDE *C:\uploads\abc.txt*#>
---------------------------acebdf13572468
Content-Disposition: form-data; name="fieldNameHere"; filename="Foo.txt"
Content-Type: text/plain
<#INCLUDE *C:\uploads\Foo.txt*#>
---------------------------acebdf13572468--

Is it ok to omit the text version of an email when it's just an "alert" notification?

Is it alright to send HTML-only emails without the text/plain part when doing HTML only actions like clicking a link to view replies or some other "alert" type notification? For example, clicking a link to activate your email or clicking to see new comments.
Date: Wed, 07 Mar 2012 10:30:54 -0800 (PST)
From: email#site.com
Subject: Test Mail
To: <email#site.com>
MIME-Version: 1.0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64
VGhpcyBpcyBdfJDFKdjfkdsFpbCBmcm9tIGxvY2FsaG9zdCB3aXRoIGZzbdrb3BlbigpIGF0IDEz
eGVvbmNyb3NzLmNvbSI+eGVvbmNyb3NzLmNvbTwvYT4gPGk+bGluazwvaT4hPHA+VGhpcyBpcyBt
b3JlIHRleHQ8L3A+
Instead of using multipart to create two copies of the same email.
Date: Wed, 07 Mar 2012 10:30:54 -0800 (PST)
From: email#site.com
Subject: Test Mail
To: <email#site.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="4f57a7d259baf"
--4f57a7d259baf
Content-Type: text/html; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: base64
VGhpcyBpcyBdfJDFKdjfkdsFpbCBmcm9tIGxvY2FsaG9zdCB3aXRoIGZzbdrb3BlbigpIGF0IDEz
eGVvbmNyb3NzLmNvbSI+eGVvbmNyb3NzLmNvbTwvYT4gPGk+bGluazwvaT4hPHA+VGhpcyBpcyBt
b3JlIHRleHQ8L3A+
--4f57a7d259baf
Content-Type: text/text; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: base64
VGhpcyBpcyBdfJDFKdjfkdsFpbCBmcm9tIGxvY2FsaG9zdCB3aXRoIGZzbdrb3BlbigpIGF0IDEz
MzExNDQ2NTgKCkFsc28gd2l0aCBhIGdvb2dsZS5jb20gdXJsIGFuZCB4ZW9uY3Jvc3MuY29tIGxp
bmshVGhpcyBpcyBtb3JlIHRleHQ=
I would like to save the bandwidth if there isn't a very good reason to include the text version.
If you're looking to save bandwidth, I don't think you should be using base64 encoding as it makes your data 33% larger (on average). In my understanding, text/plain (not text/text) should always be provided in a human-readable format (like quoted-printable).
I don't think there are many e-mail clients that can't read HTML nowadays, still I think your decision should reflect how important it is for the end-user to be able to read (and understand) your e-mail / alert and not (minor) bandwidth limitations. I've no experience with AOL, but I think it had some issues with e-mail links a few years ago, perhaps that counts as a bonus points for the plain text alternative.
Also, don't forget that the actual links need to be displayed in plain text versions.

Sending generated email. Trouble with header

I'm trying to send some html in a generated email that looks something like this:
X-Sender: XXXX#xxxx.com
X-Receiver: XXXX#xxxx.com
MIME-Version: 1.0
From: XXXXXXX#xxxx.com
To: XXXXX#xxxx.com
Date: 9 Dec 2010 10:55:52 -0800
Subject: Test email
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
<p>Click on the link below</p><p>Click Here</p>
The email sends but for some reason the link tag doesn't show up. I'm thinking it has something to do with the the content type. Any ideas? Thanks in advance.
You could try this Content-Type: "Content-Type: text/html; charset=ISO-8859-1\r\n"
It should allow your HTML to be handled properly.