For better formatting and editing possibilies I added the WYSIWYG module and the CKEditor (under sites/all/libraries). The editor is called whenever the"Formatted HTML" text format is used. Under "Configuration" >> "Content authoring" >> "Wysiwyg profiles" the configuration is done. $\LaTeX$ still works with this editor.
Currently the following notice (no error :)) is raised when content is created with this editor (see status log):
File temporary://fileJbgBFq could not be copied, because the destination directory public://js/wysiwyg is not configured correctly.
so I deactived it.
On my local installation this notice was not raised. This probably has to do with the permission-settings for this folder on our new server. Can someone help me out with this?
You were right, the folder /sites/default/files should belong to the www user, not the ftp user, otherwise drupal cannot write there. This can be changed recursively with our hoster's interface (Tools->Besitzrechte), and now I don't get an error like that when creating or updating nodes with the ckeditor. However, the user interface of the editor seems to be broken, are there maybe other files involved that one has to upload manually for the editor plugin for wysiwyg? greetz C
Thanks a lot for fixing the folder issue. In the profile for the CKEditor I added some menu items - now the user interface looks fine. When new content (like a new forum topic) is created the notice from before doesn't show up anymore. Great.
However, for some reason the editor is not called for comments. First I thought that this might be due to a conflict between the javascript of the "b2 Nice Comments" module and the javascript for the editor. But disabling this module did not resolve the issue. Any ideas?
The editor looks fine; could have used that for the LQP31 page ;-). No ideas about the comments issue
Comparing our various node types' fields with the corresponding comment fields, the field types seem to differ (long text + summary vs. long text) as well as the widgets used for their display. Could it be that wysiwyg only hooks into one of them? Changing the widget type is a delicate thing though, since drupal does not allow a posteriori changes of field types, maybe there's a corresponding conversion module? At least changing long text+summary into long should in principle be possible...
I don't think this is an issue with the different field types. I checked this on my local installation for various content types and the problem is not there, although different field types are present. also, this editor is called for individual text fields with a given text style; whether there are other fields around should not matter.
In firebug I checked the javascript errors in the console. when you try to write a comment the following error is raised:
TypeError: $(".wysiwyg", context).once is not a function
so the function (method) "once" is not known at this point. under /misc/jquery.once.js this function is defined and it is also identical to my local version. could this be another permission problem with the folder /misc, so that this file cannot be accessed?
A similar issue was discussed in https://drupal.org/node/995268. The patch provided there is the file jquery.once.js from above which eventually made it to core.
Edit: Same problem discussed here: https://drupal.org/node/1181562. Adding jquery.once.js to pixture_reloaded_lqp.info did not solve it. I don't like post #17 of this link.
post #11 of the same link did the trick at last - we now have a hacked version of the wysiwyg module, yay. (Just like with drupalchat, I don't see a clean way resembling hooks in custom modules to do this :/ )
jquery.once.js is apparently already loded by the core modules, I therefore commented the corresponding entry in our theme's info file, otherwise my browsers says he GETs it twice. ;)
Having suspected an outdated jquery included in core, our module repository is now up to date once again btw. (Didn't want to try that before LQP31 and maybe crash the site when people try finding the place ^^) I made a backup folder next to our www root containing our bzip2ed files and database.sql just like we did on univie.ac.at...
post #11 is a workaround - next time we update WYSIWYG the change is gone and we have to do it all over again. but I guess for now it works - we just have to keep track of the changes.
let's maybe give the clean solution another thought. In https://drupal.org/node/1671210 they also suggested to add the jquery.once.js script file to html.tpl.php. should we try this before we settle on a hacked WYSIWYG version?
You're right, hacking even a few lines of js is always trouble when updating. Looking into the ≷head&gr;, it seems that jquery and jquery.once are loaded, but at the end of the embedding of scripts, two versions of jquery are included again from google. Finding the responsible modules and preventing multiple occurences of jquery will hopefully solve the problem in the same way loading jquery.once at the very end (from our template) would.
As it turns out, adaptivetheme's html.tpl.php already included a statement to load jquery (did we do this ourselves?) which overwrote jquery without the once plugin. wysiwyg is now back to normal, the editor still works, and hopefully the next update of adaptivetheme will not break this again.
There is even some major version leap in adaptivetheme (from 1.2 to 3.1), but I'll better try not to install that in the middle of the day (the folder structure has changed significantly, so the theme will have to be deactivated during update).
One unclean solution remains - embedding of the opensearch.xml file was also done by hacking html.tpl.php of the theme, but hopefully we'll find a drupal function for that.
So are we using the initial wysiwyg-module now and jquery.once.js is properly loaded?
With the theme-update we should be really careful. Maybe it is possible to use one of our 4 domains as a testing environment. When everthing works fine there, we can copy the changes to the running site. These extra domains; are these subdomains of lqp2.org?
Yes, wysiwyg is now back to normal, without the #11 workaround, and jquery.once.js gets loaded (like before, but not overwritten anymore).
The domains all point to the same webspace, but a backup of the old base theme should suffice, I only meant to do that update outside the "main hours", as it can't be hidden as good as other updates...
Cool that it works the clean way now!
Right now the Editor is set for "Full HTML", so authenticated users cannot use it. Should we also set it for "Filtered HTML"? I think some "regular" users would probably also like to have more formatting options (e.g. in the Q&A).
Regarding the update: a backup is of course a must. But I would even go further to test the update on a development system (which is a mirror image of the running site) before we update the actual site. Maybe we can discuss this next week.
Should we maybe use our webspace at univie.ac.at/lqp2 as a development system? It's just in maintenance mode, but as logged in users we can still test updates there...
I think it would be better to have the development and running site "in one place". If we keep using the webspace in vienna, the question about who's gonna be the maintainer will eventually arise. But for now, I guess, it is the easiest solution.
One more remark about the issue of where to embed jQuery - as it turns out, we did in fact insert the references to jQuery, jQuery UI and the corresponding CSS files manually into the main html template of adaptivetheme. This was necessary, because the the BibTeX popup uses jQuery UI's dialog module, but overwrote the plugins of drupals own jQuery distribution, which were necessary for the HTML editor to work in comments.
I now restored adaptivetheme to its original state, and instead embedded the drupal_add_library('system', 'ui.dialog'); statement in our paper-template, which loads the js components necessary for the BibTeX popup only when necessary.
In addition, I installed the jQuery Update module, which is a clean way to keep the jQuery versions up to date (things like dialog are quite recent additions to jQuery UI), and also allows us to choose (admin/config/development/performance) between Google- or Microsoft-CDN or delivering jQuery from the site itself.
adaptivetheme has been updated on our (temporary) test site at univie.ac.at/lqp2 and furtunately does not crash it, but the layout has changed slightly (in particular, the width-restriction of the main div is somehow gone), so we can fix our inherited theme there first. ;-)
wow. the old lqp2 site looks wrecked :). let's take a look at this on friday.
Exactly. ^^ Even comparing the folder structure between the different versions of adaptivetheme suggests that there have been massive changes, but hopefully we will just have to adjust a few class names...