Articles tagged with "Administration"

I'm a fan of configuring things for display through Drupal's admin UI. It gives site builders confidence and power. What if you want to place blocks or views listings in amongst fields on pages of content? For example, to display:

• A listing (view) of related content, such as accessories for a product
• A standard contact block, advert, or some other calls to action in the middle of the content, exactly where the user is best 'caught' in their journey, rather than having to stick those in sidebars or after all the content fields.
• Some specific value(s) pulled from fields on some indirectly related entity, through a token, such as details from a taxonomy term representing the 'section' that a page is in.
• Consistent relevant links on user profiles to take people to common destinations

This is where the Entity Extra Field module (entity_extra_field) comes in. It supports embedding blocks, views or values to be replaced via tokens. So a site builder can set these up to be managed just like ordinary fields on the page (whether it's a node, term, paragraph, or any other type of content).

I recently released a new contributed module to aid translation on Drupal 7 sites: Entity Translation: Separated Shared Elements Form (ETSSEF). Yes, it has a convoluted name! It finally resolves a suggestion from years ago in an Entity Translation project issue, to allow editing untranslatable fields separately to translatable ones. One of our clients has a multilingual product database site with a few hundred fields on their content, so anything like this that could reduce the size of their editing forms is useful. I figure the best way to demonstrate this is with a recipe that blends it together...

So 2020 is in full swing, we are already midway through February and any new year’s resolutions you may have set yourself may have slipped … but why not set yourself a new resolution of keeping on top of your Drupal site maintenance? Even as a developer working with Drupal every day, sometimes you can forget some of the basics in regards to site maintenance, so I’ve detailed some of the most important aspects you should be mindful of below.

Drupal empowers site builders and editors to configure their sites in settings forms. Configuration management lets developers push changes up to live sites to be imported. But developers have to be considerate to ensure imports will not wipe out those changes made directly through the live sites' settings forms. At the least, they have to export the changes before making further tweaks. But admins may make further changes in the meantime too, so developers can end up frequently pulling irrelevant changes back from live, which seems unnecessary.

Here's some examples of the kind of config that I'm thinking of:

*...

If you don't have access to the file system on the server for a Drupal site, when a security issue like Drupalgeddon2 comes along, you are entitled to panic! Many sites are run by a combination of teams, so sometimes you really don't have control over the server... but that might even mean there is another way to apply fixes. If you've been tasked with updating such a site (I was!), it's worth checking if the server has been misconfigured in such a way to actually allow you to patch Drupal, via Drupal!

A heavy caveat first: we would never...

Much has been said about last month's highly critical Drupal security issue 'SA-CORE-2014-005', otherwise known as 'Drupalgeddon'. It was covered by mainstream international media, even if the reaction needs addressing. Drupal's security team take a responsible approach to security issues - being open & honest in disclosing them with fixes, in keeping with the community values. Security issues should always be expected in any software, it's how they are dealt with that speaks far more.

We patched all the sites that we had access to immediately fix, and informed all our clients of the issue as soon as possible. If you host a Drupal site, and haven't yet, run through the Drupalgeddon workflow right now.

Previously on this website I have written about rendering blocks programmatically and adding things to content to be managed alongside fields. It's time to combine the two! On many projects, we find ourselves needing to render a block consistently across all content of a certain type. For example:

• Are you trying to place advertising blocks or fixed javascript code between the fields in the content of a page, not just shoved into regions around the content?
• Do you want to show a standard piece of content (we use the bean module for enhanced content in blocks) to be placed...

UPDATE: The Extra Field and Extra Field Settings Provider modules facilitate doing this sort of thing in Drupal 8. Read on for older Drupal sites, and for the concepts behind this.

We often want to add things to the content of a node or any other entity in Drupal 7 using hook_node_view(), hook_node_view_alter() or a similar hook in a custom module. This could be anything from a custom social media link, a field rendered in a custom way, additional author information or virtually anything else.

Here's the code used to add that Facebook like button:

/**
 * Implements...

Part 1: Make the link work without javascript

In this example we have a table listing log entries of some kind. We want to put a delete link against each log entry allowing the administrator to delete the log entry:

The following code is responsible for printing out each link onto the page:

$query = array(
  'tok' => drupal_get_token('delete_log_item' . $flid),
) + drupal_get_destination();
$output[] = l(t('Delete'), 'admin/my-custom-log/delete/' . $flid, array('query' => $query));

The callback of which is defined by the following hook_menu item:

  $items['admin/my-custom-log/delete/%'] = array(
    'page callback' => 'my_custom_log_entry_delete',
    'page arguments' => array(3),
    'access arguments' => array('permission name')...

Here's a quick post that will be a reminder for us as much as anyone else! Setting the default theme during installation using an installation profile is surprisingly hard in Drupal 6, and easier though not obvious in Drupal 7. In Drupal 6, we used the wonderful Install Profile API module, which allowed us to do it in just a few lines in an install task:

  install_enable_theme(array('my_theme', 'garland', 'rubik'));
  install_default_theme('my_theme');
  install_admin_theme('rubik');

In Drupal 7, here's the code I use in my install task:

  // Any themes without keys here will get numeric keys and so will be enabled,
  //...