docProps or Document Properties in ckEditor 3.6 is a default feature. In order to enable this, fullPage mode should also be enabled in ckEditor.
I have done the following:
1. Implemented hook_wysiwyg_plugin($editor, $version) to add the button

function <hook>_wysiwyg_plugin($editor, $version) {
	switch ($editor) {
	case 'ckeditor':
		return array(
			'docprops' => array(
				'internal' => TRUE,
				'buttons' => array(
					'DocProps' => t('DocProps'),
				),
				'load' => FALSE, 
			),
			);
	break;  
	}
}

2. Enabled the DocProps button in admin configuration.
3. Implemented hook_wysiwyg_editor_settings_alter(&$settings, $context) to set the fullpage mode

function hook_wysiwyg_editor_settings_alter(&$settings, $context)  {
	if ($context['profile']->editor == 'ckeditor') {
		$settings['fullPage'] = true;}
}

After all these steps, the button still doesn't show in the editor. I have grouped the buttons using the method given in this link

What am I missing here?

I desperately need some help.

Thank you

Comments

TwoD’s picture

I assume you've replaced "hook" in the hook names above with the actual name of your module, or Drupal won't find them.
One way to check that the settings are being altered correctly is to print out the value of Drupal.settings.wysiwyg.configs.ckeditor.formatNAMEOFYOURFORMAT, say in Chrome's Developer Tools' Console or Firebug, it should contain the 'fullPage' settting.

First, remove the changes you made in the alter hook to group the buttons, just in case that interferes.

Did you enable the new 'DocProps' checkbox under the "Buttons and Plugins" section, added by the plugin hook?

Lastly, why do you need the Document Properties plugin? Using it, or rather the 'fullPage' mode, will not work at all with most default Drupal themes, and maybe not even with the core system. Drupal simply doesn't expect <html><head></head><body></body></html> tags in the content - all that should be handled by the theme.

anindita.b@druidendo.com’s picture

Thanks TwoD for such a fast response! I appreciate it.

In answer to your questions,

  • Yes. I have replaced 'hook' with my module name.
  • I checked the Drupal.settings.wysiwyg.configs.ckeditor.formatNAMEOFYOURFORMAT from Firebug console and it does show fullPage=true.
  • Yes, I have enabled the 'DocProps' checkbox under 'Buttons and Plugins'

Lastly, why I need this? I was looking for a way to give the users a way to apply a background color or image. I had almost started to write a custom plugin when I came across this ckEditor documentation where they mention DocProps. I must admit that I had my doubts about the <html><head></head><body></body></html> that you have mentioned. So, my question is: will this break the site? Or what will exactly happen?

After I wrote my last post, I have made some more interesting changes to my code. I have added the following snippet to ckeditor_custom_config.js which I maintain separately.

window.onload = function(){ 
	var o=CKEDITOR.instances['edit-body-und-0-value'];
	if (o) 
	{
		o.destroy(true);
	}                           

	CKEDITOR.editor.replace( 'edit-body-und-0-value',
	{                         
		customConfig : 'ckeditor_custom_config.js',
		fullPage : true,
		extraPlugins : 'docprops'
	});  
};

What has happened after this is: I can see 2 ckEditor instances in the page - one with the changed toolbar settings (my original one) and another one with the entire toolbar (it does contain the docProps too). I went ahead and tested this 2nd instance and I am able to change the background color. But it doesn't reflect after I save it. Is this the problem that you have anticipated?

TwoD’s picture

Well, you will end up with <html><head></head><body></body></html> wrapping all the contents created by the editor, everywhere. Now, if that gets rendered or not will of course depend on how your text formats/filters are configured. I'm assuming they'll most likely filter out those tags, but that doesn't stop them from being left in the database entries, which could cause issues if you ever need to migrate the contents anywhere or perhaps reconfigure the filters.
Since the Document Properties plugin most likely have set the background color/image on the body element itself, that won't show up in the rendered contents anyway.

That last snippet bypasses Wysiwyg completely so it won't have a clue what's going on behind its back (destroying/re-creating editor instances).

I'm assuming you've set the 'customConfig' setting to point to the ckeditor_custom_config.js file using hook_wysiwyg_editor_settings_alter() (or possibly added it manually using drupal_add_js() - pretty much the same thing will happen anway). That will cause Wysiwyg to create a CKEditor instance, which automatically loads that file. As soon as that file gets interpreted, the first CKEditor instance will get [partially?] destroyed (while still being initialized). Then a second instance will be created, which in turn loads the ckeditor_custom_config.js file again, starting things all over again in an endless loop (until something breaks, which usually happens soon, most likely limiting the number of visible instances to the two you see). Wysiwyg will most likely not be able to control any extra instances because it doesn't know they were created and any old references/callbacks etc will have been lost.

The instances created from within the ckeditor_custom_config.js file won't be controllable from within Wysiwyg's interface (or through the settings hook) because the settings object created by the server isn't passed to the replace() call. Essentially, chaos. ;)

Hmm, if you are using Wysiwyg 7.x-2.x-dev and CKEditor 4, you may also have to set the 'allowedContent' setting to TRUE to disable CKEditor 4's internal filtering mechanism - if content produced by a certain plugin isn't in the allowed tag list or the list is disabled, the button won't show up in the toolbar.

Since the element wrapping the user-editable contents is part of the template it can't be edited from within say a body field, meaning you can't set its background color or image. You'd need to create a secondary wrapper inside the every body field and control that instead (the div plugin should help). That's however prone to error since it's easy to forget that div, and it may not always be so easy to make it perfectly fill the space the closest wrapping element in the template occupies. Therefore, it may be better to create a new 'background color'-field and a 'background image' field which aren't directly rendered with the rest of the contents, but - if not empty - used by the [node] template itself to set style attributes in the element wrapping the node contents. Regular Image and Color (available in contrib) fields should suffice.

anindita.b@druidendo.com’s picture

I have been coding for so many years and there are only a few times that I have come across such analysis when one hasn't even seen the entire code. I am impressed!

Actually, now I have landed up with 3 instances. And you are perfectly correct about the infinite loop. I should have seen it. So, that solution is gone for good!

Thank you for the solution with the fields. I shall try it out and see how that works out.

-Annie