Drupal core announcements: Feedback needed: Dropping support for Internet Explorer 11 in Drupal 1011/30/2020 We are currently planning for Drupal core to drop support for Internet Explorer 11 in Drupal 10 (scheduled to be released in June 2022). Drupal 9 will be supported until late 2023, which means that sites that want to support Internet Explorer 11 can continue using Drupal 9 until then. Feedback needed from assistive technology stakeholdersWebAIM's survey of screen reader users shows Internet Explorer 11 usage dropping from 23.3% in October 2017 to 10.9% in September 2019. The next edition of their survey is likely to be released at the end of 2021, but we need to finalize our browser support within the next month in order to develop and release Drupal 10 on schedule. We need feedback from assistive technology users and accessibility stakeholders. Do you or your users still use Internet Explorer 11 with screen readers? Do their screen readers support browsers other than Internet Explorer 11? How feasible is it to upgrade to a different browser for use with your screen reader? We are requesting feedback until December 18th, 2020. Why would we drop support for Internet Explorer 11?
What if I need to support Internet Explorer 11?Even if Drupal 10 drops support for Internet Explorer 11, you can continue using Drupal 9 until late 2023. We recommend advising your users to move to another browser before that. If you believe your users have specific requirements as to why they cannot move from Internet Explorer 11, post them on the Internet Explorer 11 policy discussion. Would this affect Drupal 7?No. Drupal 7 remains compatible with Internet Explorer 11. A separate announcement will be issued if that changes. Originally from Drupal.org aggregator https://ift.tt/3lmg78P
0 Comments
Drupal Core News: Feedback needed: Dropping support for Internet Explorer 11 in Drupal 1011/30/2020 We are currently planning for Drupal core to drop support for Internet Explorer 11 in Drupal 10 (scheduled to be released in June 2022). Drupal 9 will be supported until late 2023, which means that sites that want to support Internet Explorer 11 can continue using Drupal 9 until then. Feedback needed from assistive technology stakeholdersWebAIM's survey of screen reader users shows Internet Explorer 11 usage dropping from 23.3% in October 2017 to 10.9% in September 2019. The next edition of their survey is likely to be released at the end of 2021, but we need to finalize our browser support within the next month in order to develop and release Drupal 10 on schedule. We need feedback from assistive technology users and accessibility stakeholders. Do you or your users still use Internet Explorer 11 with screen readers? Do their screen readers support browsers other than Internet Explorer 11? How feasible is it to upgrade to a different browser for use with your screen reader? We are requesting feedback until December 18th, 2020. Why would we drop support for Internet Explorer 11?
What if I need to support Internet Explorer 11?Even if Drupal 10 drops support for Internet Explorer 11, you can continue using Drupal 9 until late 2023. We recommend advising your users to move to another browser before that. If you believe your users have specific requirements as to why they cannot move from Internet Explorer 11, post them on the Internet Explorer 11 policy discussion. Would this affect Drupal 7?No. Drupal 7 remains compatible with Internet Explorer 11. A separate announcement will be issued if that changes. Originally from Drupal.org aggregator https://ift.tt/3moyn2u
In this short article I want to introduce you to a new module we recently released on Drupal.org, namely Multi-value form element. This small module provides a form element that allows you to easily define multi-value elements in your custom forms. Much like what field widgets provide with the Add another item Ajax button. So how does it work? Easy, really. All you have to do is define a form element of the $form['names'] = [ '#type' => 'multivalue', '#title' => $this->t('Names'), 'name' => [ '#type' => 'textfield', '#title' => $this->t('Name'), ], ]; Would give you this: And you can also use multiple form element children if you want: $form['contacts'] = [ '#type' => 'multivalue', '#title' => $this->t('Contacts'), 'name' => [ '#type' => 'textfield', '#title' => $this->t('Name'), ], 'mail' => [ '#type' => 'email', '#title' => $this->t('E-mail'), ], ]; So as you can see, no big deal to use. But all the complex Ajax logic of adding extra values is out of your hands now and can easily build nice forms. Check out some more examples of how to use this element and what options it has above the This module is sponsored by the European Commission as part of the OpenEuropa initiative and all the work my colleagues and myself are doing there. Originally from Drupal.org aggregator https://ift.tt/39s0aLZ
A few days ago Github again, prevents access to my personal private project on Github because I visited my home country last year. I decided to move my private repositories from Github to Gitlab. after migrating my project I noticed I haven't work with Gitlab for a long time and during this time it has added a lot of tools. like Bitbucket and Github it server very convenient CI/CD development that developers easily deploy their projects to servers without any cover.
Originally from Drupal.org aggregator https://ift.tt/3mmk2Uv Popular Design News of the Week: November 23 2020 November 29 2020 https://t.co/GhEaX6wQ3e11/29/2020
I have several local development environments in my machine. I would like to use HTTPS on them without much hustle. That is why I decided to create my own custom Certificate Authority to simplify the process.
Originally from Drupal.org aggregator https://ift.tt/37vIyfN Drupal is being chosen as a platform for building websites, among other things, due to its flexibility. If you want a system ideally suited to your business model and better than the competition's systems, Drupal will prove to be perfect. One of the areas you can customise in Drupal is the user permissions system. Take a few minutes to learn about the permission management abilities of Drupal. General informationDrupal allows you to manage access from the admin panel and from the code level. In this post, I will present these two possibilities and the most common examples of their use. Roles and permissions in the Drupal coreIf this is your first time dealing with Drupal and its permission system, you should know that there are three elements used for granting permissions:
When installing Drupal, you create a root administrator account in the system (identifier 1 in the database). It can be compared to the root user in Unix systems. This user has access to all subpages and settings in the system. You can add more users to the system. These could be, e.g. the editors responsible for creating the content, or the moderators deciding whether to post the added comments. If you want to assign a permission to a given user, you do it indirectly by assigning a role to them. There is no association between a user and permissions in Drupal. There is a user-role association and a role-permission association. How to add an editor role and assign the appropriate permissions to itThis is probably the most common issue encountered in Drupal. You need to let users into your system, but you want to limit their rights to the content management only. You do not want to give the rights to change the system configuration or to add new users. In order to achieve this, follow these steps:
Then log-in into the account of the selected user and check out whether they have the appropriate permissions. Maybe you need to extend them or take them away. If you are unfamiliar with the Drupal's permission system, such a test with logging-in into the user account is always worth carrying out. You do not need to know the password to the user account you want to log-in into. You just need to install the module Masquerade. Thanks to it, you can log-in into the account of any user. Drupal core permissions overviewWhen entering the page "/admin/people/permissions/" for the first time, one can get a little scared. This is probably the longest configuration page in Drupal. Let us start with the table header. You will always see the word "PERMISSION" in the first column. In the next cells of the first row, there will be the names of the roles. The more roles you add (you can add them on the page /admin/people/roles/add/), the more of them you will see in this table. Then, looking at the first column in its entirety, you will see a long list of permissions. The permissions are divided into sections. The sections are the names of modules. The "Node" section mentioned earlier is named so because the permissions in this section are defined in the "node" module (you will find it on your disk in the core/modules/node directory). Some sections have only one permission, e.g. the "Block" section has the "Administer blocks" permission only. Others have many more of them. If this is your first time dealing with Drupal permission settings, I suggest that you read the names of all permissions. The names themselves explain what a given permission is for. Anonymous & AuthenticatedThere are two system roles in Drupal that cannot be removed:
The first of these roles is responsible for all non-logged-in users. For example: if you want to add the ability to view user profiles for all non-logged-in for the "View user information" permission, tick the checkbox in the "Anonymous User" column. "Authenticated User" is the role assigned to all logged-in users. It is important here to understand the permission inheritance. If you assign a permission to "Authenticated User", then all other roles (except anonymous) will be given this permission immediately. Example: You have the "Editor" role in the system. You assign the "View user information" permission to the "Authenticated User" role. Everyone with the "Editor" role will also be given the permission because they are also considered to be logged-in users. Moreover, keep in mind that if you select any permission for the Anonymous role (e.g. "View user information" again), but do not select it for the "Authenticated User", the logged-in users will not be able to access the selected section ("View user information" – they will not have access to user profiles). Worth remembering
Own permissions in the codeSometimes there is a need to define your own permissions, e.g. to administration pages defined by new modules or to modify access to the pages defined by the Drupal core. How to define a permissionYou just need to add the modulename.permissions.yml file in the new module (or in the existing one, if you already have your own modules created). If you do not know how to create your own modules, I encourage you to visit the website. The permission file is a file in the YML format. A simple example can be found in the Popup Message module, right here. Being defined in the file is a unique name for the permission (e.g. "popup message administration"), and then – the names being displayed on the page "/admin/people/permissions/". You can provide a title in the "title" parameter and additionally – a more detailed description in the "description" parameter. This is enough to define new permissions. After creating the file and clearing the cache, you will see the new permissions on the "/admin/people/permissions/" page. How to use a permissionMost often, permissions are being used when defining routing. Take a look at the file. In the "requirements" section, you can add the "permission" parameter. In this way, you can define the users (or rather roles) with what permission can display the page defined in routing. The second method is to check out the permissions in your code. User object in Drupal has the "hasPermission" method. In this way, you can check out whether a given user has the selected permission.
It is worth to take a look at the hasPermission method here. As you can see, the user ID is being checked there. If the id equals 1, the user gets access without further checking if they have selected roles. How to check whether the user has a roleDrupal also offers a ready-made method to check whether a given user has a role with a specific name. Provided below is an example of how you can do it in the code.
Additionally, there are also methods related to the Authenticated and Anonymous roles:
How to check permissions for operations on an entityIn the application code, you can also check the permissions to operate on selected entities (e.g. Node or User). You can perform certain operations, e.g. depending on whether the user has the right to edit a given entity or to display an entity. Entities in Drupal have the method access($operation = 'view', AccountInterface $account = NULL, $return_as_object = FALSE). A simple example of use is provided below:
Defining content permissionsDrupal allows you to manage access to display and edit at the level of a single entry (node). This topic was thoroughly described in our other blog post. Grzegorz Pietrzak described it in the article Drupal Node grants. Ready-made modules for Drupal related to permissionsThere are already many ready-made modules extending the capabilities of the Drupal core. You should check them out before you start writing your own permission-related modules. Below is a list of a few selected modules that are worth checking out and testing:
Also, check the page and take a look at other modules. Maybe some of them you will find useful. SummaryDrupal is a very flexible system. Just looking at the possibilities regarding permissions, you can see the multitude of configuration possibilities. If you are building a large website with many editor levels or an internal application (e.g. an intranet system) where the users must have limited permissions, Drupal will do the job very well. If you need support from Drupal specialists on permissions or other issues, use the services of our Drupal developers. Originally from Drupal.org aggregator https://ift.tt/37dpbI3 Sooper Drupal Themes: Evaluate our Drupal layout builder now with our new and improved demo site!11/27/2020 We just launched a new free demo on try.dxpr.com that lets you test drive the DXPR Drupal experience. Thanks to our 60+ new demo pages you will be guided to explore the many exciting elements and features that are offered in our DXPR Builder and DXPR Builder Enterprise modules for Drupal 9. The new demo takes it to the next level: our demo site is based on Acquia Lightning and shows you the extent of Drupal integration of our front-end layout building application. Learn how our state-of-the-art visual authoring experience seamlessly integrates with Drupal’s multilingual features, workflow processes, and views. New minor release for DXPR BuilderToday we release a new minor version update for both our Drupal 7 and Drupal 9 branches of DXPR Builder. Most notably we now have improved native support for media entities in DXPR Builder. Whether you are on Acquia Lightning or a completely custom Drupal 9 platform, if you upload or re-use images in the DXPR Builder editor our software will automatically detect if your site supports media entities or just file entities, and create media entities when this is supported. What's next? Bootstrap 4 support!The DXPR team is working hard to bring our products up to date with Bootstrap 4. This is a large migration for us since our Drupal layout builder is based on and built around Bootstrap 3. We aim to have a release out that takes full advantage of Bootstrap 4's new features. We will also be able to improve the layout building experience by taking advantage of CSS flexbox technology, which is fully supported in Bootstrap 4. Originally from Drupal.org aggregator https://ift.tt/3o19JWh
|
AuthorWrite something about yourself. No need to be fancy, just an overview. Archives
April 2023
Categories |