If you’re using the TinyMCE wsywig editor in drupal then you may find that the editor’s background color gets set to that of your website rather than being the more normal white-ish color - this can cause the wysiwyg editor look like the proverbial dog’s dinner and depending on your websites background color/image, can make reading the text very difficult.

 

Well, the good news is that it’s easily fixed - in Drupal, go to Adminsiter/Wysiwyg menu and for each import format with which you are using TinyMCE, click ‘edit’. Once in the settings editor click on the ‘CSS’ section and in the ‘Editor CSS’ drop-down choose ‘Editor default CSS’ and save. Do this for each import format and the editor’s background should revert to a calming white.

Have you ever noticed that sometimes no debug output whatsoever appears when you call a debug output function like dprint_r() from the PHP code that you’re working on?  For example, if you call one of the debug dump functions from the default argument handler for a block view (see earlier post) you won’t see a blessed thing! It seems that there are plenty of situations in the drupal processing lifecycle where output debug information will not get through for display on a page…

 

So what’s to be done? life without debug information can get very difficult and frustrating, but not to worry as in these difficult cases we can always log our debug info to a file using file_put_contents() (as suggested here), for example if you wanted to dump information about a variable called $my_variable you could call:

file_put_contents("./drupal.debug",                  print_r($my_variable, TRUE),                  FILE_APPEND);

Then simply read the contents of the file drupal.debug, not pretty and not perfect but a whole lot better than nothing!

In drupal there are many ways to go about putting together teasers for custom content types created with the Content Creation Kit (CCK). The quickest to get up and running with is often to use the Content Templates (Contemplate) module, this allows you to specify in-line markup and PHP with code to get at and display the node’s data fields - formatted just as you require.

 

Often when putting together a teaser you may want to neatly truncate some long text to a summary and append ‘…’ or the like to the end - well there’s a great little PHP function which does just this called neat_trim() it is provided by Justin Cook and does the job  nicely!

 

One thing to note however is that HTML mark-up as well as newlines and carriage-returns in the input string can confuse this function.  To get around this problem you can arrange to remove the offending material either by modifying the function or by stripping it out of the input string before calling the function.  Use can use strip_tags() to remove HTML mark-up.

Q: How can I pass an argument to a ‘block view’ in Drupal 6?

A: There is no way to pass an argument to a block view in Drupal 6, but don’t panic as there is a way to achieve the same result through some slight-of-hand.

The use of arguments with Drupal views are vital for getting the most out of the views functionality. How are the arguments normal passed to a view?  Well, if a view is configured to produce a page then the arguments are easily passed as part of the requesting URL,  while if a view is embedded using code, then the arguments are passed in as part of the call to embed the view.  But if a view is configured to produce a block, how do you pass arguments to it?  The bad news is you can’t - the good news is that there is a way fake it and achieve the same result.

The trick involves providing a PHP handler within the view which will be called when the view is invoked without an expected argument (this is what happens when the block is displayed!).  We just arrange for this handler to retrieve and return the argument’s value and then the view will behave as required - just as if the argument had been passed to it in the first place.

To do this create the block view as normal and configure the required argument(s).  For each argument we choose the ‘Provide default argument’ option, and select the ‘PHP code’ sub-option.  We then provide some PHP code which will ‘get’ and return the argument’s value, it doesn’t really matter where or how the PHP code gets the argument once it returns the correct value.   Have a look at screen shot below:

Adding a default parameter

The example above is a bit simplistic as the PHP code just returns a static value - not very useful at all!  A more realistic or useful example  (inspired by one of the posts referenced below) would be to return the argument that was passed to the page that contains and displays the block.  Consider the mythical paths:

www.somedomain.com/content/projects/web-design

and

www.somedomain.com/content/projects/illustration

Here things are set-up so that ‘web-design’ and ‘illustration’ are arguments to the ‘projects’ page, they result in only the projects of that type being displayed.   Assuming we are using the pathauto module for nice clean URLs (as we almost always are!) then the following PHP code when provided as the default argument handler will get the URL, parse it and return the argument part to the view.

$path = drupal_get_path_alias($_GET["q"]); //get URL alias $path = explode("/", $path); //break path into an array if ($path[0] == "projects" && $path[1] != "") {   return $path[1]; }

So there is is, it’s definitely not the easiest method in the world but at least it does provide a mechanism of getting those arguments to the view…

Sources: http://drupalsn.com/learn-drupal/drupal-questions/question-2650, http://drupal.org/node/332521

For setting up a Drupal maintenance cron job on the blacknight.ie unix hosting plan, I have found that the following command works well:

 

/usr/bin/wget -O - -q -t 1 http://www.yourdomain.com/cron.php

 

Original Source: http://drupal.org/cron

We are using good old Drupal and its Content Construction Kit (CCK) once again to create a custom CMS for our client. One of the things that usually completely mystifies me time and time again is how to customise a new content type’s add/edit form layout.  So, lest I forget again in the future, here’s a link to a good article on the subject:

 

http://drupal.org/node/101092

We have finally got around to launching our new Technical Support Service for Irish Web Designers - a service designed to take care of the occasional programming and enginering aspects of a Web Designer’s Web development work, leaving them free to concentrate on the actual Web Design and Delivery.

 

This is a local service provided by experts in Ireland - so fast response times with the minimum of  administrative overhead are guaranteed.  This service is designed to be as useful for very small tasks (perhaps just an hour’s duration) as it is to larger tasks.

More details can be found here…