Skip to Content

Drupal

Phponwebsites: Drupal 7 – Hide Promoted to front page & Sticky at top of lists options

Planet Drupal - 10 January 2016 - 8:54am
    This blog describes how to hide "Promoted to front page" and "Sticky at top of lists" options from node form in drupal 7. When adding or editing a node, you can see "Publishing options" at bottom of the page which contains 'Published', 'Promoted to front page' and 'Sticky at top of lists' checkbox options. It should look like below image:


       The "Published" option is used to publish the content. The "Promoted to front page" option is used to display content in the front page. The 'Sticky at top of lists' option is used to keep the content sticked to the top of front page. If you don't want to show "Promoted to front page" and "Sticky at top of lists" options, then you can hide those options using hook_form_alter(), hook_form_FORM_ID_alter() and hook_form_BASE_FORM_ID_alter().

Hide Promoted to front page & Sticky at top of lists options in single node form:
       If you want to hide "Promoted to front page" and "Sticky at top of lists" options only in single node form, then you can remove those options from node form using either hook_form_alter() or hook_form_FORM_ID_alter() in drupal 7.  For example, we go to hide those options from article node form.
/**
 * Implement hook_form_alter().
 */
function phponwebsites_form_alter(&$form, &$form_state, $form_id) {
  // to hide promoted to front page option
  if (isset($form['options']['promote'])) {
    $form['options']['promote']['#access'] = FALSE;
  }

  // to hide sticky at top of lists option
  if (isset($form['options']['sticky'])) {
    $form['options']['sticky']['#access'] = FALSE;
  }
}
     Now you go to article node form and check whether "Promoted to front page" and "Sticky at top of lists" options are hidden or not. You couldn’t see those options in article node form. It should look like below image:

Hide Promoted to front page & Sticky at top of lists options in multiple node forms:
     If you want to hide "Promoted to front page" and "Sticky at top of lists" options in all node forms, then you can remove those options using  hook_form_BASE_FORM_ID_alter() in drupal 7.
/**
 * Implement hook_form_BASE_FORM_ID_alter().
 */
function phponwebsites_form_node_form_alter(&$form, &$form_state, $form_id) {
  // to hide promoted to front page option
  if (isset($form['options']['promote'])) {
    $form['options']['promote']['#access'] = FALSE;
  }

  // to hide sticky at top of lists option
  if (isset($form['options']['sticky'])) {
    $form['options']['sticky']['#access'] = FALSE;
  }
}
     Now you could not see those options in all node forms. Now you know how to hide "Promoted to front page" and "Sticky at top of lists" options from node form in drupal 7.Related articles:
Add new menu item into already created menu in Drupal 7
Add class into menu item in Drupal 7
Create menu tab programmatically in Drupal 7
Add custom fields to search api index in Drupal 7
Categories: Drupal

Théodore 'nod_' Biadala: Drupal gets a feature request out of the blue

Planet Drupal - 10 January 2016 - 2:42am

Word is that Drupal is getting a frontend framework. From the multiple options it seems EmberJS is currently a little ahead of Angular and React. As said in Dries original post as well as in the drupal core issue created, nothing is final and everyone interested is asked to check that the set of library in the comparison is sufficient and more importantly that the criteria used for evaluation are relevant.

Discussing those details is not what this post is about, like others I've been questioning the move from Dries. Since many of us are professionals, let's put this in a professional setting and pretend that Dries is just another client making a feature request seemingly out of the blue. To him the problem and solution is clear — obvious even — and it is the only way to achieve his vision. Let's check.

Client side (pun intended)

Drupal's user interfaces for content modeling (Field UI), layout management (Panels), and block management would benefit from no page refreshes, instant previews, and interface previews. These traits could also enrich the experience of site visitors; Drupal's commenting functionality could similarly gain from these characteristics and resemble an experience more like the commenting experience found in Facebook.

Should we decouple Drupal with a client-side framework?.

Pretty weak set of reasons. What is described later in the post can be achieved though regular Ajax and some resonable amount of javascript. Hardly a need for a frontend framework… until you remember what else Dries has been writing about.

As the Drupal community, we need to stop thinking of Drupal as a "content management platform" and start looking at it as a "digital experience platform" used to create ideal visitor experiences.

From content management to digital experience management.

Ideal as in enriched as in, for example, Acquia Lift. Don't get your pitchforks just now, there is no hidden agenda, just finish reading.

How serious is the client

Sometimes features can be swept under the rug and everyone will feel better in the long term. Sometimes the client does not let it go. So how serious is Dries about this? The two posts directly related to frameworks contain 3 387 words and if you include the related posts you can add 10 394 more words. A busy person doesn't write a short story just for fun. So I'd say he is pretty serious about this, and if you read the trail of posts this is not going away.

Client needs

We know a few things about what the client is trying to address:

  1. He expects the web to be completely different in 10 years.
  2. Most sites will need personalization.
  3. Better UX is crucial.
  4. One solution fitting core and contrib.

Since there needs to be one solution, it has to be in core from the start because contrib is not disciplined enough (by design) to come up with one homogeneous solution in less than 10 years.

A little extrapolation

If you have in mind all the posts Dries has been writting on the topic for the past two years it makes sense that web components or websockets do not address the issue of rich interfaces the way a frontend framework would, also in this discussion any PHP-based solution is off-topic. It looks to me that Dries is trying to get the community as well as Drupal ready for what he believes is coming. I deeply disagree on what the future holds for the web but it doesn't mean nothing should be done, just in case. At worst we'll burn the new people who came to help us switch to the new framework.

Solution

All in all, I would agree that under those assumptions, a framework is a valid tool to be using. Putting my JS maintainer hat on I would suggest to jQueryUI-it. Put it in core and use it anecdotally, and hope contrib will pick it up. Also we should chose the framework with the strongest opinion on how to do things. Because Drupal back-end is rather strongly opinionated about what the PHP should look like. It makes sense the JS should be the same.

On Acquia bashing

I've spent more than 2 years as an Acquia consultant, working closely with the Office of the CTO on several big D8 improvements so I've seen how the community is treated from the inside and I've only seen good will towards it. Sometimes things are downplayed, not out of malice, but out of concern for the issue at hand. Which is why I think Dries didn't explicitly mentioned Acquia Lift — but still hinted to it — to not get dragged in an argument about Acquia's influence. There is nothing wrong with that since compared to the fears expressed during D8 cycle, we're far from the worst scenario possible.

On that topic, when people say that Acquia, big companies or startups are influencing Drupal I think they're taking a shortcut. It's more like Acquia clients are influencing Dries, and in turn he steers Drupal to what he thinks is right. But don't forget that between clients and Drupal there is a filter, it's Dries. So far I think we can agree he's been pretty great at Dictatoring Drupal. So let's at least give him the benefit of the doubt.

Put your pitchforks back and grab some paint, there is a bikeshed to paint.

Categories: Drupal

ARREA-Systems: Build a custom calendar module in Drupal 8

Planet Drupal - 9 January 2016 - 5:15pm
Build a custom calendar module in Drupal 8 Submitted by JK on Sun, 01/10/2016 - 08:15

 

In this article we will describe how we created the calendar in our back-office management application EK (see demo).

 

 

For this function, we used the FullCalendar plugin and its dependencies.

1) Create the Drupal 8 library

In a file called MyModule.libraries.yml, insert the following css and js configurations:

Categories: Drupal

Akshay Kalose: Drupal 8: Create a Simple Module

Planet Drupal - 9 January 2016 - 3:05pm

Drupal 8 came out with many new features and updates at the end of 2015. As Drupal 8 is object oriented and enforces PSR-4 standards, the way you make modules has significantly changed. However, this change makes modules much more organized to fit today’s coding practices. I will be demonstrating how to create a simple … Continue reading "Drupal 8: Create a Simple Module"

The post Drupal 8: Create a Simple Module appeared first on Akshay Kalose.

Categories: Drupal

tanay.co.in: Drupal 7 to Drupal 8 Migration - 101 and Observations

Planet Drupal - 9 January 2016 - 10:42am

So, Drupal 8 has been out. And Migrate framework is now part of core! I haven’t had a chance to try out a D7->D8 migration so far. Knowing that this would be something I might do probably a hundred times in the coming couple of years, I thought of giving it a try.

I will now attempt to migrate this current Drupal 7 website (www.tanay.co.in) to Drupal 8. I shall be taking the MigrateUpgrade-UI path (than the drush path) as described on https://www.drupal.org/node/2257723 . I don’t expect a full-replica of my current site on D8 at the end of this attempt, but we shall take a look at what worked, what didn’t work.

I used 8.0.2 version of Drupal core, and 8.x-1.x-dev release of Migrate Upgrade module.

These observations might probably NOT reflect the current state of the Migrate Upgrade module. It is highly likely that the module performs better than what is observed below - ie, Some issues noticed in this attempt might have already been fixed in the Migrate Upgrade Module.  Chances are also high that I missed some steps or screwed up something.

  1. Download and enable the migrate_upgrade module

  2. Navigate to the /upgrade path on your website

  3. Populate the Source SQL details and the site url to fetch files from

  4. This will show you a list of available and missing upgrade paths.

  5. Hit the “Perform Upgrade” button. Fingers Crossed!

  6. Still running after 5 mins.. Drupal seems to be doing some serious loads of stuff here..

  7. While I was waiting, I thought of checking out the sites/default/files folder on my Drupal 8 site. As I assumed nodes are now being migrated, probably the assets are being fetched. In which case, the sites/default/files should be filling up. Yep, it indeed is being populated..

  8. Let’s check out what is up with the Drupal 8 Database. Yay! It is being populated as well!

    Well, interesting to see that the node table on D8 doesn’t have the title column. I wonder where the titles sit now in D8. There doesn’t seem to be any node_title, node_field_title tables.. Well there seems to be a new table here though. It is node_field_data which seems to hold the titles of the nodes!

    Hello there node_field_data table! Good to see you. I am sure we are going to bump into each other many times in the coming days!

  9. Cool. Let’s switch back to the browser tab where the upgrade was running and see how things are going.

    Wow,. here we go! The upgrade is now complete.

First Look at the website:

The migration has definitely surprised me. I was expecting a lot of broken stuff. But it already looks good. The site seems to have all the content that I care about. I was surprises to see that some of the blocks of static markup, disqus comments that I had at various positions on the D7 site were migrated as-is into almost similar positions on the D8 site. I never expected that to be the case! I was expecting just the nodes and terms being moved around. THIS IS AMAZING so far...

 

Blocks were auto-migrated!

URL Aliases also seem to have come through fine!

Let’s edit a node and see how it looks…

Term References look good!

Although I am not sure if this was the case with only the default “tags” vocabulary. Probably even custom term reference fields added to custom types also get migrated just fine. Unfortunately, I don’t have such custom term reference field on my site to verify this.

All the content types look good!

This is amazing that all the content  types were just re-created by D8 using their structures from D7, at the click of a button!

Let’s open a content type, both in D7 and D8 and see how they compare. I am taking the most used content type on my site - The Article content type that I have got, which I use to post blog posts like this one.

D7:

D8:

Discounting Meta Tags field (that came from a contrib module), all fields look good.

 

The Image Field Attachments are broken :-(

The content type “article” had an image field and a file field. The file field rarely had any files attached but the image field had an image for every blog post. So, what happened to these image attachments:

The Image field was created on the D8 content type automatically by Drupal

The files were fetched and copied from the source site into the D8 sites/default/files folder

An entry was created for each file in the D8 site files table and these files can be managed from “admin/content/files” on the D8 site.

But the images were NOT attached by the migration to the relevant nodes


Let’s see how good things are. Before we check out how things are on the new D8 site with the old content from D7, here are a few things I am interested in:

  1. The content (nodes) obviously

  2. The term references (I don’t have any node references. So I am not bothered about it right now)

  3. Meta Tags (from the D7 Metatags module). This has 2 items of importance

    1. Checking if these tags themselves are migrated. AFAIR, I haven’t used the metatags module to store any per-node keywords on the module’s storage but the meta-tags are made to appear on the node pages using terms from a term reference field attached. So, irrespective of the migration path of metatags module the terms themselves would probably have been migrated into the D8 site if term reference migration worked on #b above

    2. The display of the metatags in the markup - I am not much bothered about them at this point of time. I don’t expect the upgrade to have ported the contrib metatag module configuration as well. Should be good as long as I have the tags available somewhere on the D8 site. I will probably configure the module afresh on the D8 site using tokens similar to those used on the D7 site

      Considering the use of taxonomy for metatags, I could probably discount metatags in defining if the migration was any useful.

       

  4. Images (Each blog post has an image attached to it on an image field). Also, each blog post has a large number of images embedded in the markup (Usually pasted into the WYSIWIG and retrieved automatically by Drupal 7 using https://www.drupal.org/project/get_image module)

  5. URL Aliases / Clean Urls

As such these would be the items I would care about in the migration and see how Drupal 8 at its current state, using the migrate_upgrade path of migration has fared on these items - Content, Term References, Images, Url Aliases

Content

Was well-migrated. Content types were auto-created on D8 by migration. All nodes were migrated without skipping any. Most of the field and content type display configuration was replicated on the D8 site.

References

Looks good. There was only one vocabulary. It was replicated on D8 and all terms were auto-migrated.

Images

The Image field was created on the D8 content type automatically by Drupal

The files were fetched and copied from the source site into the D8 sites/default/files folder

An entry was created for each file in the D8 site files table and these files can be managed from “admin/content/files” on the D8 site.

But the images were NOT attached by the migration to the relevant nodes

Clean Urls / Aliases

Migrated

NOTE: I am not referring to the pathauto settings. But the existing (generated) aliases for existing nodes were migrated.

Site Configuration

This was the item where I was surprised the most. Blocks, Block Configuration, Content type Configuration (Comments etc), Site-wide configuration (Image Styles) were migrated from the source D7 site to D8 without any effect.

Overall, the migration has surprised me. The only significant issue that stood out for me was that the images were not attached to the nodes. There were a couple of smaller issues that I could stumble upon - Like, some of the migrated image styles had the labels missing. I am pretty sure the issue with the image field attachments is logged somewhere on the Issue queue of core or migrate_upgrade module, wherever it fits best. I haven’t verified that. I will probably check that out later.

Thumbnail Image used on Listing - D7 to D8 - is courtesy of Drupalize.me

 
Categories: Drupal

Drupal core announcements: New Coding Standards Update Process

Planet Drupal - 9 January 2016 - 10:07am

The Technical Working Group was rebooted about a year ago and has been working to clarify and close issues related to the technical aspect and ramping up to take on our biggest assignment: vetting, clarifying, accepting, and announcing all coding standards changes.

Historically there has been no official process for coding standards changes and these issues and the nature of them are notoriously difficult to get developers to agree on leading to endless bike-shedding and difficulty in finding complete consensus. To this end we have worked with interested community members to draft and approve a new policy for reviewing, deciding, and announcing new coding standards changes. To that end we have created a new Drupal TWG twitter account to announce the list of issues for consideration, this list will be posted on the Core groups.drupal.org group and linked from the twitter account.

All coding standards issues have been moved from the Technical Working Group issue queue to the new Coding Standards project, the maintainers of which will be the Coding Standards Committee. The Committee will be composed of members appointed by the Technical Working Group and any documentation maintainers (listed in Drupal Core’s maintainers.txt) will be automatically invited to join.

Meetings are held every two weeks where new issues can be identified for inclusion. The first meeting to review and include issues for the first round of updates to coding standards has been scheduled for January 22nd, at which time the committee will review coding standards issues tagged “Needs announcement for final discussion". Issues that are deemed ready by the committee will be included in the announcement following that meeting, at which time a final round of community feedback on the proposed changes will be appreciated. At a subsequent meeting the final discussion will be evaluated and issues may be ratified as official changes.

Categories: Drupal

Twig Whitespace Collapser

New Drupal Modules - 9 January 2016 - 6:30am

Enables the Twig Whitespace Collapse Extension created by Mat the Cat that merges spaces, tabs and line breaks in templates before compilation.

Categories: Drupal

Intense

New Drupal Modules - 8 January 2016 - 10:47pm

Provides a simple Intense image field formatter. A stand alone javascript library for viewing images on the full screen. Using the touch/mouse position for panning.

All styling of image elements is up to the user, Intense.js only handles the creation, styling and management of the image viewer and captions.

Categories: Drupal

Freshdesk Single Sign On

New Drupal Modules - 8 January 2016 - 10:44pm

This module enables you to use Drupal as a single sign on (SSO) source for Freshdesk.

You can create as many SSO configurations as you need, and each one has it's own individual permissions.

Needs before release:
  • Documentation
  • Handle redirect url parameter
  • Test coverage
Categories: Drupal

Field Collection View Modes

New Drupal Modules - 8 January 2016 - 7:43pm
Synopsis

When using field collections, a view mode can be associated with each field collection item which will then control the display of fields in the edit form for that particular field collection item.

For example, assume a field collection for a content type contains three fields:

  1. field_subtitle
  2. field_image
  3. field_extra_text

and the three view modes for this content type are:

Categories: Drupal

NYS Global Navigation Integration

New Drupal Modules - 8 January 2016 - 1:06pm
Overview

All state of New York websites are required to have the Global Navigation (sometimes called Agency Navigation) bar at the top and bottom of the site
surrounding any other content. This module makes it easy to integrate them on a Drupal site.

Categories: Drupal

David Lohmeyer's Blog: Improving Drupal 8 core search when using multiple content entity searches

Planet Drupal - 8 January 2016 - 10:58am

Drupal 8 allows you to create multiple search pages which show up as primary tabs on the search page after performing a search. This is cool, but has the limitation of making the user input a search term a second time when they navigate to the other tab.

Categories: Drupal

Dream permissions

New Drupal Modules - 8 January 2016 - 7:10am

This module facilitates the management of permissions, it allows you to exclude roles and modules from the management screen.

The management page uses ajax to load the relevant permissions, you have to select at least one role and at least one module, otherwise you don't get any results.

You can filter the roles and modules on any part of the name

This is mainly a proof of concept, but is working. It also doubles as a show case on how javascript can be used to improve the user experience.

Todo:

Categories: Drupal

Mediacurrent: One Word to Save your Project

Planet Drupal - 8 January 2016 - 6:57am

When faced with requirements that threaten to break the budget, blow the scope, derail the schedule and generally destroy a project, there is one magic word that can come to the rescue.

Why.

Asking “Why?” can help clarify, or neutralize, potentially destructive requirements and ultimately save the day.

Categories: Drupal

Deeson: The Curious Incident of the Wrong Theme being used after a Cache Clear in Drupal 7

Planet Drupal - 8 January 2016 - 4:30am

If you are using Drupal 7, have multiple themes enabled, are using hook_custom_theme() to choose the right one and find that after a cache clear the first page load chooses the wrong theme, then this blog post is for you.

On a couple of recent projects we have been using hook_custom_theme() to set one of several active themes for a given page request. This is a really useful hook allowing us to change the look and feel for different parts of the site. For example, we might use a different theme if a page is part of a Drupal Group which makes it look like a sub-site.

We were seeing an odd behaviour where the site default theme would load on the first page request after a cache clear, rather than the one we were returning from our hook_custom_theme implementation. Debugging showed that hook_custom_theme() was being fired and our implementation was returning the right option during the first page load.

Subsequent page requests following the first after a cache clear would result in the correct theme being used. The problem was that if that first page was opened by an anonymous user it would get varnish cached and all users would see the page in the wrong theme for a few hours.

The reason

The problem is the functions we were putting into hook_custom_theme().

hook_custom_theme() along with hoot_url_inbound_alter() and hook_boot() all get called very early in the drupal boot cycle and not everything has been properly initialised at this point, including the correct theme. If you call code that assumes this has happened then odd things can happen.

Following a cache clear the menu needs to be rebuilt - and this is a complex operation which calls a lot of code and prematurely sets the site to use the default theme.

If you access the menu, for example by using ​menu_get_item, ​menu_get_object or even node_load​ in these functions you will trigger a menu build too early and initialise the default theme. 

Solutions

The solutions are to keep the code in the hooks which run before the theme is initialised as simple as possible.

For example, do you need to load the menu to decide the theme or can it be infered from the current path? Rather than load the whole node, can you do a simple db_select on the node table to get the information you need?

Categories: Drupal
Syndicate content


Google+
about seo