Frequently asked questions
FAQ
Frequently asked questions
Not necessarily. JIT mainly benefits CPU-heavy tasks like data processing or scientific calculations. For most web apps, performance gains will come more from I/O optimizations (like caching or database queries) than from JIT.
No. PHP 8 is backward compatible with most PHP 7 code. You can adopt features incrementally—start by using new syntax in fresh code and refactor older parts gradually over time.
Yes, many organizations transition existing Drupal sites into headless setups. It usually involves reworking the frontend to consume Drupal’s content via APIs while keeping the backend for content management.
Organizations that need multi-channel content delivery, want to leverage modern frontend frameworks, or require top-tier performance and scalability are strong candidates.
In many cases, yes. By decoupling, the frontend can be optimized independently—often deployed as static files on a CDN—resulting in faster load times and better SEO performance.
Yes, it typically requires more development expertise since the frontend and backend are managed separately. However, the added flexibility and scalability often outweigh the initial complexity.
Custom modules should be placed in the modules/custom directory. This keeps them separate from core modules (in core/modules) and contributed modules (in modules/contrib), making upgrades and maintenance easier.
At minimum, only the .info.yml file is required for Drupal to detect a module. Other files are added depending on the functionality you want, such as a .module file for hooks, a routing file for custom pages, or configuration files for default settings.
A typical custom module includes:
- An .info.yml file (required).
- An optional .module file if hooks are needed.
- Optional YAML files for routing, permissions, and menu links.
- A src folder for PHP classes such as controllers, plugins, or forms.
- A templates folder for Twig template overrides.
- A config folder for configuration and schema files.
You can add configuration to a Drupal module in several ways:
- By providing default configuration files inside a config/install folder.
- By defining configuration schemas inside a config/schema folder.
- By creating administrative settings forms where site administrators can change values.
- By using Drupal’s configuration API in your code to read or update settings.
Pagination
- First page
- Previous page
- …
- 6
- 7
- 8
- 9
- …
- Next page
- Last page