I am using the Workbench suit of modules and I have a simple change to make to node-edit forms.
I simply want to alter the labels on the buttons at the base of a node add/edit page to something more customized for our purposes.
The image above shows my attempts to re-label some buttons on a node/add page. Using hook_form_alter, there is only access to Drupal's native set of buttons - I am able to edit the PREVIEW button to TESTING PREVIEW.
However, I cannot seem to find a way to edit the workbench module related buttons - Send to moderation and Save as draft.
Can anyone offer suggestions on how to access these extra buttons?
Actually, the best solution turned out to be a custom module.
The issue preventing me from seeing the data for the Send to moderation and Save as draft buttons was due to the weight of my module.
Using the Modules Weight module to my modules weight appropriately so that it executes after the Workbench modules then allows my module to see and adjust all the data other modules add, for example, button labels, visibility etc.
I just discovered the Strings Overrides module.
Works like a charm.
Related
The GridFieldExtension module comes with a GridFieldRequestHandler class which would enable extending the default GridField detail view (eg adding tabs or breadcrumbs). Unfortunately this feature is not included in the module's documentation.
Q: Can this class be used to add the following functionality to the GridField detail view?
Back Button
Save & Close
Delete
Userfriendly breadcrumbs
I'm familiar with the module BetterButtons that includes all these features, but it would be unnecessary to install yet another mod it if this mod already enables these features.
In this case I would suggest using the Better Buttons module instead of using GridFieldRequestHandler. The Better Buttons module is well maintained, full of features and works right out the box.
I don't believe it's worth writing all the code needed to use GridFieldRequestHandler to reproduce the Better Buttons functionality. I think Better Buttons is the right tool for this job and it warrants being installed even if we already have the GridFieldExtension module installed.
I'm trying to create a simple module to preview themes in Drupal. Each user has their own custom node and I want to be able to show them a preview of how the theme will work without them actually enabling it. Right now this is what I have:
function theme_preview_info($new_theme, $node_id)
{
global $custom_theme;
$custom_theme = $new_theme;
$node = node_load($node_id);
return $node->body;
}
It will display the content of the node, but the formatting is all messed up. How can I properly display the node exactly as it would as if i went to node/1, but instead view it at theme_preview/theme_name/1?
Do you have any experience building Drupal modules?
If not, you may find that what you are trying to do is not all that simple.
You will need some interface for the user to choose which theme they are previewing. Then, you will need to hook into Drupal's routing to direct users to the appropriate node using the selected theme preview based on a customized path alias (theme_preview/theme_name/1). There's most likely a lot of other back-end overhead that I'm not anticipating at the moment.
If you have experience with building Drupal modules, though, that might not be a big deal.
Switching out the theme is probably the easiest part. If you're in Drupal 7, you can use an implementation of hook_custom_theme() to change the theme used for particular nodes based on your intended criteria (i.e., which theme the user selected).
http://api.drupal.org/api/drupal/modules--system--system.api.php/function/hook_custom_theme/7
This way, you can actually allow Drupal and the selected theme to completely handle the rendering of the page, giving a more accurate preview.
I'm not sure how exactly you would go about creating the user's theme-switching interface or routing the user to a specific path alias for each theme selection.
You also might want to look into the ThemeKey module (http://drupal.org/project/themekey). It's possible you could use that module somehow to simply set up ab version of each node to be viewed in each different theme.
What is the difference between using the WYSIWYG module pointing to the CKEditor library and using the dedicated CKEditor module.
We currently use the WYSIWYG module with TinyMCE.
The answer seems to be that with the Wysiwyg module, you get an interface for which buttons appear in the profiles, whereas with just CKEditor, you don't? Or at least it's not obvious where choosing which buttons appear happens in the CKeditor module. http://drupal.ckeditor.com/ has some documentation on the subject, which says you can change the buttons.
http://drupal.org/node/606404 for some background on why CKEditor and Wysiwyg are separate efforts (though you can use CKEditor just fine with Wysiwyg).
I'd be inclined to stay with Wysiwyg so that you can swap out editors (that is, the JavaScript libraries for them) without having to swap out Drupal modules.
The CKeditor module gives you have much more granular control around where the editor windows appear, user role level permissions and the buttons available for each. The WSYIWYG API just allows for basic on/off configuration of editor windows for text fields across the whole site. Button profiles are based around input types (filtered & full HTML). The advantages of the API module is that it's not limited to just one editor (there's 10 or so) and really easy to configure.
The Ckeditor module is more difficult to configure and certainly not for most implementations, but very nice to have this module available if you require that level of control.
From my experience, using the Wysiwyg module was a better decision.
In some special cases (mainly when the editing was inside of an Ajaxed page), using ckeditor was a bad chioce.
When using the Wysiwyg, replacing the editor itself wasn't a hard task, which solved several problems very fast.
Therefore, for future situations you might not even think of now - use the Wysiwyg module.
Using the WYSIWYG module will allow you to fairly easily switch to another editor if you find one you prefer (or if new ones come onto the market).
RE: WYSIWYG module using CKEditor library vs CKEditor module
I found the former only allowed the following toolbar;
(source: johnathanthwaites.info)
Later had much more like font colour, flash embed, spell check etc.
(source: johnathanthwaites.info)
Have done a full explanation here;
Link to CKeditor
I have some nodes I am displaying in a view. They are displayed as nodes, unformatted. I would like the user to be able to choose from some predefined sort criteria ( via drop down list or similar).
So they could pick recently active, most commented, newest, etc., and re-query for new results.
Its easy with tables because you can make the labels clickable, but I do not know how to have similar functionality with a raw node preview display.
Just a thought, from me to me, and for anyone else who may be trying to do this.
An easy, sleezy option would be to just add another page view for each of the required sorts, and provide a link to these other views in the header of each of the pages.
This could also allow for (easier) linking to the individual sorts, so say if you have a sidebar block displaying recently commented nodes, you could adjust the .tpl.php of the block to have the title link to the view displaying the full set of recently commented nodes.
also im pretty sure there should be a way to do this with arguments, but i dont know how
Views 3 supports exposing sort order (just like you can expose filters)
Select the sort order (e.g. add sort by node creation date, then click on the settings for that), you should be able to expose the sort order to the end user. This is just like clicking on the settings for a filter and then choosing to expose it.
Standard views isn't going to support this, so IMO you're best off implementing a custom solution using just a plain old view and this jQuery plugin. You can either do this at the theme layer (the same way as any other JS in a theme) or a custom module (via drupal_add_js() to add the plugin and your bit of custom code). Either way will work, although the custom module has the obvious benefit of being theme independent (and thus more portable).
If you go the custom module route, please consider releasing it as a contrib module on http://drupal.org.
In Drupal, is there a way to create new content (based on a content type that uses CCK) in a popup or lightbox or similar technique?
There are at least two worlds that I know of:
http://drupal.org/project/popups_reference which uses http://drupal.org/project/popups
and
http://drupal.org/project/noderelationships which uses http://drupal.org/project/modalframe
Both of these are about creating the node in a modal in order to reference it via a node reference field. There might be ones for more general purposes, or you could probably adapt one of those. I've been enjoying noderelationships lately. Haven't tried the other recently.
The projects sprugman refers to are useful when you need to create a referenced node while you're adding another node. If you simply want to make the /node/add/[contenttype] link to open in a lightbox, try the Lightbox2 module.
There is a great module in Drupal automodal that works with Modal Frame API. What you need to do is simply add a new class 'automodal' to your links... and the magic is done for you.
Another one is the Modal Nodereference module. Here is a quote about it (from the module's project page):
... turns the nodereference widget into a modal popup allowing new linked nodes to be created on the fly. Because it uses an iframe, it should support even Javscript and file uploads within the sub-node.
The big feature: It should work with editors, image fields, and all of those other JavaScripting things. We built it precisely to meet those needs. We started with modalframe, instead of one of the other popup libraries, because we knew that we could make this work with TinyMCE, CKEditor, and ImageField -- libraries that have difficulties dealing with other popup APIs.
It depends on the Automodal module, as well as the excellent Modal Frame API module.