1. الرئيسية
  2. Drupal development policies

Drupal development policies

These policies is a nice to have features and is expected to be used whenever applicable.

 

Git

We all commit and push only code/files that we know, and that we are responsible of. So, please make sure to review your code before add it to the repository. And push files that make sense to all project environments. Something like (git diff habit before commit is a must to help you avoid pushing print_r, exit, dd or die functions).

URL Structure

Please obey the Drupal breadcrumbs when you decide to create new path. You know Drupal will handle the breadcrumbs for you when you build it like this: /manage ... /manage/people .... /manage/people/{user}/edit .. So, Drupal will treat these paths as a parent and child.

Custom module name

Please use the project name as a prefix. PROJECT_* .. also make sure to use singular and simple name. PROJECT_user instead of PROJECT_users. And PROJECT_register instead of PROJECT_registration.

Content type names

Content type names should be singular, not plural. بصيغة المفرد وليس الجمع .. مثال: صفحة .. استفسار .. طلب .. This is applicable to Paragraph also.

Machine name: NOTE: Content type machine name if it is sub for another content type, please use the first character of the parent content type as a prefix for the sub content type. e.g. Organization content type (organization) have a sub content type for Employees (employee) the content type machine name should be (o_employee) instead of (employee). And the field related to employee should be prefixed by field_oe_*. Please don't miss to include the prefix of the bundle (field_noe_) Since it's related to node.

Content type settings

  • The revisions always should be enabled and for important contents the revision log should be required. Always enable Create new revision

  • Disable Preview before submitting option from (Submission form settings)

  • Disable Promoted to front page

  • If you want to enable the translation for the content type. Please check only this option Enable translation from the (Language settings). Please DO NOT show the selector on create/edit pages. Because the translation always should be added as the site default language and then translated to the other available languages.

  • Disable Display author and date information from (Display settings)

  • Disable all Available menus for the content if not applicable. from (Menu settings) tab.

Taxonomy vocabularies:

Vocabulary name should be plural, not singular. بصيغ الجمع وليس المفرد. .. مثال: المدن .. أنواع العضويات ..

Fields

  • All fields should begin with a general namespace that the field is associated with. This makes it easier to find related fields.

  • Node fields attached to bundles (aka content types) should include the first character of the content type machine name and should have a suffix if it is one of these types (computed) or (shared between more than one bundle).

    • CANCELLED POINT: The _shrd (shared) should be used as suffix for fields that can be attached to multiple bundles.

    • CANCELLED POINT: The _cmp (computed) should be used as suffix for fields that are calculated and are not editable.

    • CANCELLED POINT: `The _ref (reference) should be used as suffix for fields that are reference another entity, make sure to write the entity name as a field name (field_po_organization_ref) is a field in (Property ownership) content type referencing (Organization) content type.`

    • The _text (text) should be used as suffix for fields that must be a dynamic field but for special case it is only text field. Like birthdate in Hijri, mobile number if it is in textfield. etc.

Patterns

  • Node

    • field_{first_character_of_bundle_name_node_n}{content_type_first_character}_{field_name}_{field_type_shrd_or_cmp_ref}

      • Example of type field in Article content type: field_na_type n: for Node. a: for Article.

  • Taxonomy

    • field_{first_character_of_bundle_name_taxonomy_t}{vocabulary_first_character}_{field_name}_{field_type_shrd_or_cmp}

      • Example of type field for Categories vocabulary: field_tc_type t: for Taxonomy. c: for Categories.

  • User

    • field_{first_character_of_bundle_name_user_u}_{field_name}_{field_type_shrd_or_cmp}

      • Example of id_type for user: field_u_id_type u: for User

  • Paragraph

    • field_{first_character_of_bundle_name_paragraph_p}_{field_name}_{field_type_shrd_or_cmp}

      • Example of file field in experience paragraph: field_pe_file p: for Paragraph. e: For Experience.

More examples

  • field_no_cr_number (field for Organization content-type)

  • field_u_display_name (field only for user profile)

  • field_tc_color_code (Color code of [C]ategories vocabulary)

  • field_no_rating_cmp (field for Organization content-type, computed field will be calculated by the system and not editable)

  • field_full_name_shrd (Shared field between more than one bundle)

 

Helper functions

Always start with (is, get, load). The difference between get and load is the get has process in it. But the load it loads directly and it returns always a big giant object, not a specific small thing.

(Data) or (Details) in function and variable names. use (Details) when we get data not exists in the database directly. and use (Data) when you just structure the DB data. fo example getUserData() ... getUserDetails() ...

Ref:

 

Creating new view

  • Rename the display to list if it will list a specific list of content. otherwise rename it to a proper name. but please don’t keep it page_1

  • Whenever you can expose some filters in the list please do. (maximum 5 filters if not requested by the business) Always think of the operation people.

  • Use a proper sorting for the view results.

  • If you will create multiple search filter, please use `

  • Always use 50 results per page

  • Add views result counter. Add new field View result counter and make it the first column.

  • Add Result summary to the footer of the view. to show how many results in this view.

  • Always use (permission) to manage the view access. Please do not use role or any other options.

    • For custom logic access. Please RouteSubscriberBase and set _custom_access as a new requirement for the view route. (Please ask for help if you need)

  • Views on production:

    • Please make sure to change the “access” on the view directly. You need to save the view after setting the proper private access since it is by default will be public.

    • Please always use this prefix “temp-20230802-VIEWNAME-YOURNAME” like “temp-20230802-listing-users-saud.

 

Menus

  • You need to know that Drupal is handling the menu items as per current user permissions. So, make sure to use a proper access for the routes before adding it to the menu. And always re-use the menu for multiple roles as much as you can.

  •  

 

Revisions