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.
Related
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.
How to edit and save back the default tridion template building blocks say for Ex(Default Finish Actions) provided by SDL?
Where can i found the soucre of default TBB's? After locating and editing the TBB's, how to save back in TCM?
Editing default templates provided by SDL is not supported. They are stored in DLL and there's no way you can customize it. Maximum you can do is to disable some of the templates from being created. Alternatively you can can create your own set of default templates.
You can use the Template Builder to assemble and (test) run Compound Templates (Page and Component Templates). You can access the Template Builder from the Tools tab in the Ribbon.
The default TBBs should not be changed.
.NET TBBs are either C# fragments with the code directly accessible, or classes that implement the ITemplate interface.
Please see the following blog post to get you started:
http://www.createandbreak.net/2011/11/template-building-blocks-via-net.html
The code for (an older version of) most of the Default Template Building Blocks can be found on the Tridion forum (http://forum.sdltridion.com).
(I don't have access anymore, but maybe somebody can edit my answer and provide the link)
As others have said though, you risk getting into support trouble if you simply modify and replace them. It might be better to:
take the code from the forum as a starting point
create your own variant, making the modifications you need
compile this into a new TBB
replace the standard TBB in the Default Finish Actions with your own variant
That way you can accomplish most things, without risking support problems. When they doubt whether you broke is, you can just swap out your own variant for the original and prove them wrong.
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've posted this on the drupal forum too btw)
I'm converting the company websites to use Drupal, or at least trying to check that its going to be the best way forward. I have a background in PHP development, and I'm currently using the CakePHP framwork. I've built this site (not my design) and I can see how to replicate most of the functionality using Drupal, most likely using the CCK module.
http://preview.tinyurl.com/yk6u8mt
As you can see from the homepage:
A user chooses a country.
The country is passed using an ajax call to a script that decides which phone is best based on 'in country' network coverage.
A div is shown recommending the visitor the best phone for that country.
I'm wondering how to go about this in Drupal, I'm definitely not after a step by step guide, I just want to know if this kind of thing is possible with Drupal, and what approach to use.
If someone can help that would be superb. Thanks.
Okay, so you've got a path you're defining in hook_menu, which is where your form is being presented - or else you've got it set up as a webform in a node, that could work too.
Either way, in your form you're going to be using AHAH - check out http://api.drupal.org/api/drupal/developer--topics--forms_api_reference.html/6#ahah and http://drupal.org/node/348475 .
Basically, you're going to define another path in hook_menu that's of type MENU_CALLBACK, and which will receive the country as input, and then will return the div that you'll display on the screen.
One core example of AHAH that may be useful to you is where you're entering a password and it lets you know if the password is secure enough - check that out.
Edit: There's also some good examples at http://drupal.org/project/examples.
I would look into using CCK and views. you can set up filters for the views. If filters don't work, you have the ability to include php code. I have also successfully added jquery code in the header of a view through which I was then able to have my view filtered by what is typed in a text box.
Coming from CakePHP using Drupal is a pain in the a** - even more for developers.
It's application structure might be designed to ease extensibility but this only means you have a system to enable your own plugins and themes.
While modules are basically the M+C-part the themes are the V-part of an MVC-application. The problem is that this seperation is not very strict in Drupal - in fact you have to break it sometimes in order to make things work (e.g. you have to include a theme_mymodule_myfunction() into your module as default output which you then can override with your theme using mytheme_mymodule_myfunction() ) And don't even bother looking for classes ( see http://drupal.org/node/547518 ).
Also there is no real link from a module to a theme. On many occations this is a good thing as you can switch modules and themes seperatly without creating a problem. For application builders coming from CakePHP (or any other framework) you often feel a lack of "wholesomeness" - you create parts for a base software and have to live with it's drawbacks.
IMHO I wouldn't recommend this step. Drupal is fine if you have to manage a website and might add a few modules to add neccessary value (image gallery etc.) but I definetly don't recommend it as a base for a customized web-app.
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.