WP MU 1.3.3 Advanced TinyMCE v0.5.0. Проблемы с div и классами css

День добрый!
Возможно поможет кто то с проблемой следующего характера:

  • Установлен WP MU 1.3.3 и Advanced TinyMCE v0.5.0.
  • Подключены внешний стиль через панель управления TinyMCE.
  • В стиле используются классы выравнивания картинки и "обворачивания" в рамку. (Стандартные классы плагина Flexible upload).
  • Эти же классы добавлены в стиль, используемый в теме.

При форматировании текста и вставки картинки посредством Flexible upload все выглядит корректно (картинка выравнивается и формируется css рамочка вокруг), но по нажатию кнопки "Сохранить" либо "Опубликовать" результат остается неформатированным.

При следующем анализе происходящего определил, что из кода начисто вырезаются все div и классы, присвоенные картинке (как впрочем, и всем остальным элементам). Т.е. WP пропускает весь HTML код через что то типа фильтр валидности.

Гуглил 2 дня и практически ничего не нашел по решению этого вопроса, кроме статьи с сайта Sonika (http://www.sonika.ru/blog/wordpress/wordpress-visual-editor-3.htm) о прописывании своих стилей, хотя я раньше сделал это сам, и статьи с сайта плагина TinyMCE о проблемах с WP и TinyMCE (http://www.mkbergman.com/?page_id=383).

Пожалуйста, если кто то сталкивался с этой проблемой (а, думаю, по мере потребности, с ней сталкивались многие) и нашли решение, помогите, пожалуйста.

Очень бы хотелось полноценного использования классов стилей в Вордпрессе.

Вариант, предложенный в статье о проблемах с WP и TinyMCE попробовал, но без положительного результата.

Заранее, большое спасибо за помощь.

Привожу вырезку изстатьи о проблеме WP и TinyMCE:

Changing Code Processing

Since at least the WordPress 2.1 release, the TinyMCE editor has had the nasty habit of removing <div> tags when toggling between ‘Visual’ and ‘Code’ views.

This comes from the WP team’s (arbitrary) decision about this matter (and many others, see below). The code causing this nasty change is in the initial configuration file for TinyMCE, generally found under this path:

/path-to-wordpress/wp-includes/js/tinymce/tiny_mce_config.php

In that file you’ll see this code:

$valid_elements =
‘p/-div[*],-strong/-b[*],-em/-i[*],-font[*],-ul[*],-ol[*],-li[*],*[*]’;

What this code basically says is to replace all <div> tags with <p> tags, <b> and <i> with <strong> and <em> respectively, keep all font and bullet tags, and then, as a capper, keep all remaining all other tags not specifically listed (*[*]).

Actually, this is all pretty good practice to use valid XHTML, except for the curious <div> replacement.

TinyMCE offers nice control of such parsing matters, but it definitely is not a good idea to make changes directly to the WordPress supplied configuration files. Rather, I isolated such changes to the Advanced TinyMCE plug-in code itself. Thus, this code is now added to the plug-in advanced-tinyMCE.php file:

function extended_editor_mce_valid_elements($valid_elements) {
 $valid_elements = '-strong/-b[*],-em/-i[*],-font[*],-ul[*],-ol[*],-li[*],*[*]';
 $valid_elements = apply_filters('extended_editor_mce_valid_elements', $valid_elements);
 return $valid_elements;
}

Note that the only change I made was to remove the unwanted <div> with <p> replacement.

Note, you could make your own changes within these same lines of code. For example, Moxiecode provides a set of instructions to make your code completely XHTML compliant (see bottom of page). That documentation and related material on the TinyMCE wiki site are probably worth inspecting if you are going to get aggressive about making your own code changes (but, proceed with caution!).

Of course, these are fairly fundamental changes in that they act to re-write underlying page code. Use at your own risk and you are on your own!

Спасибо всем посмотревшим 🙂
Сам разобрался, так что, если у когото возникает подобная проблема, то делаем следующее:

Создаем файл kses.php следующего содржания:

<?php
function addabitofclass( $tags ) {
    global $allowedposttags;
    foreach( $allowedposttags as $tag => $attr ) {
        $attr[ 'class' ] = array();
        $attr[ 'id' ] = array();
        $allowedposttags[ $tag ] = $attr;
    }
    return $allowedposttags;
}
add_filter( 'edit_allowedposttags', 'addabitofclass' );
?>

и сохраняем его в каталок mu-plugins.

И.. наслаждаемся наличием классов в визуальном редакторе и в результирующем варианте поста 🙂
Big thanks to Donncha and Farms

Anonymous
Отправить
Ответ на: