heavenbr / wordpress-custom-content-type-manager

Automatically exported from code.google.com/p/wordpress-custom-content-type-manager
0 stars 0 forks source link

WYSIWYG fields incompatible with 3.3 #271

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem? (Be specific enough so that someone
else can make the plugin fail for themselves. Remember: if the issue can't
be fixed if it can't be reproduced!)

1. WordPress 3.3
2. Try using a WYSIWYG field using 0.9.5-rc3

This produces deprecated errors: stuff changed in WP 3.3.  The TinyMCE 
implementation is better, but it's still problematic.

 * http://codex.wordpress.org/Function_Reference/wp_editor
 * http://nacin.com/tag/wp_editor/

The new approach is difficult because the editor ID must be ONLY lowercase 
letters.

One possible quick fix would be to integrate the wp_editor() (and bypass the 
tpl stuff), force the id_prefix to be only 'cctm', and alert the users that the 
names of WYSIWYG fields must only contain letters.

Original issue reported on code.google.com by ever...@fireproofsocks.com on 27 Dec 2011 at 5:04

GoogleCodeExporter commented 8 years ago
Due to WP's frustrating limitations, this field can't be repeatable: the trick 
I was using required PHP and Javascript to be able to iterate a counter to 
identify each field instance.  PHP can do this trick:

$var = 'a';
$var++;

But Javascript cannot, so we can't sync these up without moving all the 
Javascript functionality of adding and deleting fields to Ajax requests, and 
that's just a ridiculous workaround when the problem that should be addressed 
is WP's poor implementation of TinyMCE.

See this forum post: 
http://wordpress.org/support/topic/wysiwyg-wp_editor-limitations-in-33?replies=1

Committed revision 481737.

Original comment by fireproofsocks on 29 Dec 2011 at 6:20