FCKEditor visibility and drupal paths

By nightmarepatrol on 30 Nov 2008 at 23:37 UTC

I've been reading the forums most of today trying to sort out how to solve the problem of maintaining the FCKeditor visibility (or invisibility as the case may be) when editing nodes.

Specifically certain node types should be created ann edited in plain text, however other node types (ie. blogs) should be created and edited using the FCKeditor. I have tinkered with pathauto and manually defining content urls. Maintaining the editors visibility process can easily be managed during the creation process, however if the node is to be edited I keep winding up with the node/xx/edit path which mungs up the whole editor presentation/managability thing with the FCKeditor. So I have been looking (for almost a whole day) at a way to say having the node edit path be representative of the content type rather than NODE/XX/EDIT.

So I was looking at the custom_url_rewrite_inbound found at (http://api.drupal.org/api/function/custom_url_rewrite_inbound/5:) to attempt to manage this. However I don't want to take down the entire site by inserting a core hook into my settings.php file.

So am I barking up the wrong tree? If so which direction should I be looking in? Or... am I on a pointless venture to try and manager the FCKeditor visibility in drupal 5.12?

Comments

Anybody have any

nightmarepatrol commented 1 December 2008 at 14:50

Anybody have any suggestions?

My last attempt

nightmarepatrol commented 2 December 2008 at 02:35

I'm 0 for 2 in my last two posts requesting wisdom. :(

My last attempt at bumping this topic...

Fckeditor also supports

WorldFallz commented 2 December 2008 at 03:04

Fckeditor also supports visibility settings by id-- perhaps you could alter your content type fields to add a class that ties the content type to the textarea-- then just use the id to include/exlude the field for fckeditor use.

_{===

"Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime." - Lao Tzu

"God helps those who help themselves." - Ben Franklin

"Search is your best friend." - Worldfallz}

I'm not sure how I would go

nightmarepatrol commented 2 December 2008 at 14:18

I'm not sure how I would go about assigning a class to a field that is in the core module. I like to stay in the scope of best practices whenever possible and I don't really want to screw around with core modules. Is there another way to go about this?

You are right not to want to

WorldFallz commented 2 December 2008 at 17:09

You are right not to want to stray from best practice or modify core files. But no worries, drupal is designed to extend things-- you just have to do it the 'drupal' way.

Probably the easiest way to do this would be to use cck fields for all text areas in each of your content types (you can replace the standard 'body' field with a cck text field also)-- then you will have a unique id (like 'edit-field-bodytext-0-value') for which you can enable/disable fckeditor. As long as you don't reuse the fields on different content types it should work as expected. You can even name the fields the same (ie 'bodytext') and cck will automatically append a digit to make the field name, and therefore the id as well, unique. I would probably just work the content type into the name of the fields (i.e 'storybody') so it's obvious and easy to remember where they belong.

The other, more complex option, would be to theme the individual content type forms.

Either of these options is far superior to somehow mangling the edit URL which i'm pretty sure will have adverse consequences.

fckeditor visibility settings

Fíona commented 2 December 2008 at 21:57

I have just discovered that I can use the editor to create content on a new page but not to edit content on an existing page.
I understand that this issue has to do with "The ID for excluding or including this element is: edit-body - the path is: node/3/edit" except I can't understand how to use the visibility settings. The default setting is set to "exclude". I don't want to change that to "include" and add the edit-body bit above as I assume the default is set to exclude for a good reason.

I cannot find any (for me) clear instructions as to how to use these settings and be able to edit my content with the editor.
Will anyone please point me in the right direction

This is essentially what I

nightmarepatrol commented 3 December 2008 at 00:27

This is essentially what I have been describing. The default to exclude fields. It depends on what your goal ultimately is though. For my current project I will only have a few areas that will require any special markup so using the settings in inclusive mode will work better. However, of path name used by drupal when editing a node changes to node/xx/edit rather than editing the node by something that say pathauto would assign I wind up in a conundrum. I don't want to have HTML markup in ALL the nodes, but that's what you get when a node is edited. Worldfallz has offered up a path for me delve down. I'm not sure how I'm going to duplicate the blog module via CCK, but we shall see how it works out. Of course I could also go look for contributed module too.

Anyhow, I do appreciate the feed back and guidance from people here.

I'm not sure how I'm going

WorldFallz commented 3 December 2008 at 01:05

I'm not sure how I'm going to duplicate the blog module via CCK

You don't have to duplicate the blog module-- just edit the blog content type, disable the default body field, and add a cck text field as I described above.

A means to do this

nightmarepatrol commented 3 December 2008 at 18:46

Since I can't to in through the normal admin route to disable the body field, would the next best thing to be go into the node_type table update the blog row setting the has_body colum to be a 0? Is that an acceptable means of disabling this or is that a non-best practice means of doing this?

Since I can't to in through

WorldFallz commented 3 December 2008 at 19:23

Since I can't to in through the normal admin route to disable the body field

Why not? Are you receiving an error of some kind?

If I go to Admin > Content

nightmarepatrol commented 3 December 2008 at 20:01

If I go to Admin > Content Types and edit the Blog entry content type there are no managable fields there.

Ah ok-- I should have been

WorldFallz commented 3 December 2008 at 20:36

Ah ok-- I should have been more explicit. Navigate to admin/content/node-type/blog, expand the "Submission form settings" fieldset, and simply delete the word "body" from the 'Body field label' texbox. That will disable the body field. Then you can go to admin/content/node-type/blog/fields and manage the rest of the fields normally.

Oddly enough that does not

nightmarepatrol commented 4 December 2008 at 00:48

Oddly enough that does not work even though it says it does in the text below. The same hold true for my Drupal 6 installation as well. It's also possible that I need "new glasses"

I did find an interesting tidbit earlier at http://drupal.org/node/225909 that makes an interesting suggestion.

If I don't find a solution I may have to try altering the node_type table directly (provided I do a backup first of course)

I'm still thinking that my head is harder than the wall though. :)

This issue evidently runs deep

nightmarepatrol commented 4 December 2008 at 14:17

In my journeys into this I found many many posts about the settings page for all content types (including blog entries) stating that removing the body field label does not work as advertized.

Someone submitted at proposed patch for it on node http://drupal.org/node/223771 however I don't think it will see D5, so it looks like I may have to do something I really don't want to, (ie, vi the blog module)

My bad-- i had completely

WorldFallz commented 4 December 2008 at 16:50

My bad-- i had completely forgotten that I form_altered my body field away.

You don't need touch core for this-- that's the beauty of drupal. You can cleanly override just about anything.

If you have a custom module for your site (I always make one named after the site for little snippets just like this) just add the following function:

<?php
function blog_form_alter($form_id, &$form) {
  $form['body_filter']['body'] = array('#default_value' => '', '#rows' => 0, '#required' => FALSE);
  return $form;
}
?>

I'm not sure all 3 of those array values are necessary to make the field disappear, but it just made logical sense to me to clear all of them.

If you don't already have a module you can make one by putting the code above in a file called "mymodule.module" in a directory called "mymodule" (or whatever you want 'mymodule' to be) and then add a mymodule.info file as follows:

name = Mymodule Custom Code Module
description = For custom code snippets

EDIT:

if you only want to do that for certain content types (ie blog) change the code to this:

function blog_form_alter($form_id, &$form) {
  $node = node_load(arg(1));
  if ($node->type == "blog") {
    $form['body_filter']['body'] = array('#default_value' => '', '#rows' => 0, '#required' => FALSE);
    return $form;
  }

That's the direction I was

nightmarepatrol commented 4 December 2008 at 16:58

That's the direction I was going to go look at next. Other than going after the blog module itself that appears to be my only option to accomplish this and I really don't want to touch the core modules.

Thanks for the example, I believe I'll start with that and post mt my results once I'm satisfied with them. I'm sure there is at least someone else reading (or might read this) that needs this solution.

Thanks for all your support in this, I really appreciate it.

After playing around a

WorldFallz commented 4 December 2008 at 18:15

After playing around a little I found this to be the best/shortest way:

function mymodule_form_alter($form_id, &$form) {
  if ($form_id == 'blog_node_form') {
    $form['body_filter']['body'] = '';
    $form['body_filter']['filter'] = '';
    return $form;
  }
}

And you're welcome ;-)

EDIT: i changed the hook to the proper name (after the module). I think I got my original code from the thread you linked above which 1) doesn't work and 2) is incorrect.

And it works

nightmarepatrol commented 4 December 2008 at 21:02

:) Thanks again!

finally, lol. glad to

WorldFallz commented 4 December 2008 at 21:19

finally, lol. glad to help.