When reporting issues/behavior, you must include your details: versions of WP and of the CCTM, otherwise I have no idea how to comment on this. WYSIWYG fields in particular had to be completely rewritten for WP 3.3: WP’s implementation of TinyMCE is particularly problematic.
If the behavior is verifiable, please file a bug in the bug tracker: http://code.google.com/p/wordpress-custom-content-type-manager/issues/list
Sorry, my wrong:
WP 3.3.1, CCTM 0.9.5.5-pl, I have tested several scenarios in this installation as described in my former message. I will file a bug then.
Thanks. The bug tracker keeps me sane.
For the record, Bug info is here: http://code.google.com/p/wordpress-custom-content-type-manager/issues/detail?id=292
Basically the question is whether or not you want the CCTM to forcefully REGENERATE the p tags that WP strips by default. The wpautop() function could be added to all WYSIWYG fields so that their output is processed before it shows up in your templates… not sure if that’s the best solution or if it’s better to let users do that on their own.
Thank you for clarifying. I’m quite new to WordPress, though not new to webdevelopment.
From a user / integrator perspective: implementing a WYSIWYG field should always show the same behaviour. Creating a paragraph in the WYSIWYG editor should create a paragraph.
My advice would be to not forcefully regenerate, but to add a line of documentation to the sample template, or create a setting which can be toggled.
The major problem is that WP devs do not have modular code, especially here with the WYSIWYG fields. It seems through and through that the devs never really expected the WYSIWYG editor to appear anywhere else but in the main content block. Cracks in this started to appear in 3.3 with the rewrite of the editor stuff, but it’s still hardly a poster-boy for modularity.
It does make sense to have repeatable behavior between instances. I could add a global setting to CCTM to dictate this.
Guys, guys… there’s a simple fix, no need for bug tracking etc…
just apply filters in the template when you print the_content
<?php print apply_filters('the_content',get_custom_field('clientCustomWysiwygEditor')); ?>
Why this wasn’t this added to the sample templates in CCTM ages ago is the real question…
We sourced the technique here:
http://wordpress.org/support/topic/plugin-types-custom-fields-and-custom-post-types-management-wysiwyg-auto-p
Your welcome 😉
Guys, guys… there’s a simple fix, no need for bug tracking, modular core, global settings etc…
just apply filters in the template when you print the_content
<?php print apply_filters('the_content',get_custom_field('clientCustomWysiwygEditor')); ?>
The real question is why this wasn’t this added to the sample templates in CCTM ages ago?
BTW we sourced the technique here:
http://wordpress.org/support/topic/plugin-types-custom-fields-and-custom-post-types-management-wysiwyg-auto-p
You’re welcome 😉
