Managed to get past the error I was having and am now on 7.1.0 release (not p710). I’ve got a custom type that uses several different rich text fields. At some point it worked, but now… it no longer works when I paste in text to a rich text field. I’ve tried putting it in source as well. If I just type in the text, golden, but not when doing a copy-> paste. There’s no obvious error. And I have an afterSave on my object that does a flush of objectBroker. If I dump the object from there I can see the data not be updated when I paste in information, but it’s there when I just type it in. Maddening.
Are you saying that when you paste text you can see it in the rich text editor but when you save it and then click edit again the text is gone?
Can you update to the latest of p710 and see if the issue still exists? There have been object broker fixes which could be related.
Correct and will do.
7.1.1 (which is what the admin is reporting) is having the same issue. It may just be my custom type as I’m sure a ton of people would be screaming if this were happening everywhere. The fields are all named unique names, and the seq values are all different.
Can you do another test for me?
Create a brand new object (don’t edit an existing one), paste some text into TinyMCE, then save. In the top right corner of the object overview window there is a small icon that dumps the object, click on that and see if your text is in the property that you pasted it into.
Failed as well. I only completed two fields (there’s 4 wizard steps). Only the title and one of the richtext fields. It did not save the richtext with pasted text. I tried having hit “next” to get through all the wizard steps and as well as just hitting complete from the 3rd step after pasting the text.
When I test locally on the latest p710, I can paste both plain text from a text editor and rich text (HTML) from a web page (not that you would normally do that, it’s better to paste into Notepad or a text editor first or to toggle on TinyMCE’s “Paste as text” option on the toolbar).
How large is the text that you’re pasting into TinyMCE? A few words? Several “pages” worth? If you’re using Adobe ColdFusion and the content that you are pasting is longer than your DSN settings allow then it may not be able to send all the data to the DB server, and so the object might not be saved. To fix this you might need to increase the number in the Blob Buffer field.
Does it fail even if you just copy a few words of plain text copied from Notepad or a text editor? If that’s the case, I don’t think the problem can really be related to pasting?
The other possibility is that there is a problem with your content type / database schema. Check your Admin -> Dev Tools -> COAPI Conte Types page for conflicts and resolve them if there are any. Then you should also check your fourq.log or coapi.log to see if there are any entries at the same time as when you are saving, perhaps they will give us more info about the error.
Where would those logs be at? I’m rolling Railo 3.x and not ACF.
The Railo logs will generally be under your webroot in WEB-INF\railo\logs*
“INFO”,“web-0”,“07/16/2015”,“20:49:45”,"",“Unable to locate webskin [edit] for typename [product]”
“INFO”,“web-0”,“07/16/2015”,“20:50:05”,"",“Unable to locate webskin [edit] for typename [product]”
“INFO”,“web-0”,“07/16/2015”,“20:50:10”,"",“Unable to locate webskin [edit] for typename [product]”
“INFO”,“web-0”,“07/16/2015”,“20:50:11”,"",“Unable to locate webskin [displaySystemFU] for typename [product]”
Those all seem fine.
Was the Admin ->Dev Tools -> COAPI Content Types page clear of any conflicts?
Free of any changes waiting to be deployed. I guess I’ll start backing out the richtext’s and adding them in 1 by 1 until I find out which one is blowing this up.
How many richtext fields do you have in your component? Which DB are you using, MySQL? You might be hitting the row size limit.
35 total fields for this object. MySQL is indeed the DB. The text I tried to past in last was:
Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry’s standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged. It was popularised in the 1960s with the release of Letraset sheets containing Lorem Ipsum passages, and more recently with desktop publishing software like Aldus PageMaker including versions of Lorem Ipsum.
Ahhhhh ok… That’s a lot of rich text fields 
Your problem might be the MySQL row size limit then.
Is it an InnoDB database? For InnoDB you can edit your my.ini/my.cnf to change the default storage format of InnoDB files, you’ll probably need to add these 2 lines in the [mysqld] section somewhere below default-storage-engine=INNODB
innodb_file_per_table = 1
innodb_file_format = Barracuda
After making this change, you will need to restart the MySQL service. This only affects newly created tables, so you’ll need to make a change to the table for your content type so that MySQL re-creates it. This should do the trick:
ALTER TABLE yourTableName
ENGINE=InnoDB
ROW_FORMAT=COMPRESSED
KEY_BLOCK_SIZE=8;
If it’s MyISAM, there might be some other workaround, but I haven’t had to deal with that yet myself.
1 Like
Can you post the <cfproperty> tags for the content type?
Any luck with the database changes?
I think it’s turned out to be a UTF-8 issue. Once I using TextPad as an intermediary I was able to paste into the fields just fine. I’m not sure if it’s a Railo issue (older version, need to update it) or a MySQL thing.
Ok, just keep in mind that the MySQL row size limit could be a factor for your content type, because it has 11 longchar fields in it. Whether or not you have a problem will depend on how many of your longchar properties have data in them, and how long the data is in each of them (note that this applies to all type="longchar", not just ftType="richtext").
For InnoDB the maximum row length is 8000 bytes, and for these fields the first 767 bytes get stored in the row. If all 11 fields had 750 bytes in them then you will definitely blow out the row size limit and records will appear like they aren’t being saved.
I would recommend checking to see if your DB is using InnoDB and if it is then do some testing with data in each of the fields to see if it’s going to fail at some point
1 Like