Hi Jennifer,
I saw you're todo item on the module front page - so I took the cue and implemented some additions to this module to allow for creating and managing templates through the database.
I've built in the administration, allowing the templates to be created, modified and deleted. The editing of the templates themselves is done through a Wysiwyg interface. Then for loading in the templates to TinyMCE, it uses menu hooks to load dynamic JavaScript files for the template list and the individual templates.
I hope this is what you had in mind - honest feedback is appreciated!
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | wysiwyg_template_rework.patch | 20.04 KB | guybedford |
| #7 | rework.patch | 13.32 KB | jenlampton |
| #2 | wysiwyg_template.patch | 21.5 KB | guybedford |
| wysiwyg_template.zip | 12.15 KB | guybedford |
Comments
Comment #1
jenlamptonGreat work so far, I'd love to get this UI into the official release! Thank you so much for contributing :)
1) does the template creation really belong at admin/content? wouldn't it be better at admin/settings/wysiwyg_templates/templates, or better yet. Let's move the settings for wysiwyg template to admin/settings/wysiwyg/templates and add the template creation onto the same page. We can keep creation as a sub-tab, with a list of available templates on the template page (along with the directory settings - or maybe instead!)
2) do you really want your HTML template to be Filtered? This template will end up inserted into a node body anyway, which is also filtered. This seems like an additional strain on the system, and I wonder if there's a benefit.
3) can we add a "delete" operation as well as "edit"?
4) I'm not sure I fully get the "Selected content classes" idea. My guess is that you are trying to automatically replace one piece of the template with content, but I'm not sure the description text makes that clear, and I'm not sure why you'd want to do that. Let's chat real-time about the use case.
5) Creating a node, the template is not inserted. 1) go to node/add/page, 2) select an input format with a wysiwyg editor using the template buttons 3) click the button to insert a template 4) select your template from the drop-down 5) click insert. 6) Nothing happens.
Next time, can you create a patch to the existing module with your changes? (info on creating patches)
Comment #2
guybedford commentedThanks for the feedback.
I've added in CK editor and FCK editor compatibility. I researched the other editors, but none of them offered straightforward templating implementations that I could use without getting into custom addons.
Responses on your points included below.
1) I've moved all the admin pages into the admin/settings/wysiwyg/templates path. This is much simpler and it works well having a single place to do these changes.
2) Unfortunately, I can't see a way to embed a Wysiwyg editor without using an input format. Unless it involves using a custom embed code. I really wish it wasn't there though - I'm very tempted to throw in some JavaScript to hide it.
3) The delete button has been added to the form.
4) I was bringing in the selected content classes as mentioned in the issue by Ju. I wasn't actually able to get it to work, and have just removed this for now. We can potentially bring it back if it is a required feature.
5) I've been unable to replicate this problem. Perhaps it's some kind of input format filter hiding the template, or stopping it from applying? In TinyMCE, the template is loaded from the following URL - wysiwyg-templates/tinymce/load/%tid - where tid is the id of the template. Perhaps check this url and see if it's displaying ok there?
If you want to discuss any of this further in real-time just let me know. I look forward to seeing where this module can go.
Comment #3
lance.gliser commentedPardon gentleman, but I was thinking of starting to build this exact same thing. I hope you don't mind some input.
1) I think you're missing out on some potential power by forcing the templates to exist under the admin at all. Drupal's got a very good reason for using nodes. I think the templates themselves might be best included using those nodes. For things like a site designer role, they would want views to be able to see all content types such as "Site Banner" "Content Template" etc. Putting these templates at the command of the larger system would let people get exactly what they need. In addition, you could easily rely on CCK at that point for your input output, and people add informational cck as they required.
3) Node controls : )
Thanks for taking this up. A fine addition to a very useful module.
Comment #4
guybedford commentedHi Lance,
Thanks for your suggestions. It's always interesting to discuss this stuff.
Typically though, nodes are considered as content, which a template is certainly not. We'd be using the nodes purely for their ability to provide listings, edit and delete functionality (which has been the primary subject of development for an admin interface for templates already!).
I struggle to see what other benefits are provided by such a system.
I'm also not quite sure how CCK would be used. Are you meaning this to be meta information on the template?
Guy
Comment #5
lance.gliser commentedAye. That I am. Here's my reasoning, something I'm considering doing for a client soon.
The immediate payoff for using nodes would be a way to offer more customization of the template browser. A fairly common way of inserting "content" (we can argue what qualifies later), into a WYSIWYG is to provide a view of a type of content. This lets each user's site modify the view as they need to add filters. This has been a huge win for us already using Image Assist. My standard image assist view includes an extra exposed filter for title, as well as tags on the images. I'd love to have a way to sort through the potentially many templates in the system by tags I put on them.
As soon as you have need of that kind of extra meta data, you'll need permissions automatically handled for the most part by node and field controls.
My example here is specific to my reality, because that's just what I know. But I'm trying to think long term. If you drop the templates into nodes, you allow the rest of the development community to extend it without concerning yourself about what potential uses they need. If you lock it down, you'll be responsible for satisfying or denying the needs future adopters come up with.
Comment #6
guybedford commentedOk, I get you. I can see it could be a useful feature to have template groups with permissions for different users. But not so sure there'd be many other benefits offered by CCK. There's no reason it couldn't be implemented as part of the template admin interface instead of the node interface.
If you can think of any further compelling reasons, do mention them!
Comment #7
jenlampton@guybedford, thanks again for all your work on this
2) Of course you need to use an input format on your node when inserting the template, but I've removed the input format selection from the template creation page admin/settings/wysiwyg/templates/add (or edit). It does not need to be specified there. I also improved the description text a little, with links to the other settings.
4) Let's get the new UI working, then add back in the class selector as a feature request, later ;)
5) Let's drop this for now and move on.
6) The callback at admin/settings/wysiwyg/templates should not be a form. It's just an overview page, so should maybe call theme_table instead, which gets rid of the need for another theme function just to return a table.
7) We need to add admin/settings/wysiwyg/templates into the active trail on the admin/settings/wysiwyg/templates/add and admin/settings/wysiwyg/templates/edit pages so that it shows up in the breadcrumb.
8) Watch your indenting and comments. We should add the proper function header definitions, where missing. You can review Drupal coding standards here: http://drupal.org/coding-standards
All but #8 are included in the attached patch.
Comment #8
avibrazil@gmail.com commentedThe rework.patch doesn't work for me.
On admin/settings/wysiwyg_template I get emptyness and the following message:
warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'wysiwyg_template_admin_settings' was given in /var/www/html/includes/form.inc on line 371.
Comment #9
guybedford commented@jenlampton No problem, I just hope we can get this released as soon as possible.
The patch seemed to only apply to the main module file, and didn't include the additional files. I've brought through any changes in the patch that were there.
2) I removed the input format - the templates are now plain html.
6) I adjusted this to just work through the table theme function.
7) I've played around with the menu to get the trails, but the breadcrumb on the edit page is looking very odd. Any suggestions welcome.
8) Reworked comments and indentation
Comment #10
lance.gliser commentedAny motion on this? I'm still interested in an outcome, and still think nodes might be the way to go.
Comment #11
guybedford commentedFinally got the admin interface out. Not using nodes, although still open to suggestions for future releases.