Overriding Varbase
Last updated
9.0.x
Last updated
Create custom modules and have your override in them.
Basic hooks like hook alter.
Use and dispatches.
with a custom or extended Class.
In case of capturing a bug. Search if it was filed in an issue. Look if the a patch fix for the issue was uploaded.
Example: In the composer.json file for the project:
Please add the "Issue Number" and the URL for the used patch
An introductory patch for an enhancement over a Varbase component or any Drupal project is welcomed.
A patch may not be committed on the spot. It will need review, and testing for what affect it may do for websites.
There may be situations in which you want to ignore a patch supplied by a dependency. For example:
You use a different more recent version of a dependency, and now a patch isn't applying.
You have a more up to date patch than the dependency, and want to use yours instead of theirs.
A dependency's patch adds a feature to a project that you don't need.
Your patches conflict with a dependency's patches.
Example:
Let imagine that the Drupal core release team had a new release, But they had committed the following issue:
The patch fix for the core issue was added when a fix was needed for the following issue:
At the point of a new release for Drupal core and in case the patch was committed.
Ignore the patch being used as in the following example method:
If you use the URL to the Gitlab MR directly, your code base will change without warning, as people work on the merge request.
Recommended to use the local patch method in this case.
Download the .diff or .patch file in a patches folder in the project.
Add the module name, issue number, and date for the MR changes to the name of the file.
Add the patch local patch to patches.
Example ( NOT Recommended ):
Example ( Recommended remote patch file ):
Example ( Recommended local patch/diff file ):
WARNING: The URL for a Merge Request patch file will be named after the MR and will not change as more and more commits are being added to the MR. The contents of the patch file will change, however.
Therefore, it's strongly recommended to lock the patch file versions on production sites. To do so you must download the patch file and use it in composer from a local directory, or upload it to the same issue as a file. If you use the URL to the Gitlab MR directly, your codebase will change without warning, as people work on the merge request.
Do not keep patches or patches-ignore for long in projects.
Keep track of them, and clean not needed patches.
Report back if you'd spotted and committed patch. So it will be removed from the module.
Report back if you'd spotted a better patch logic and standard. So it will be used instead of the old patch.
Using the composer plugin with
The module is requiring Drupal Core with "drupal/core": "~9.0", . Having number of patches to fix issues or overriding Drupal core.
Issue : Fix tour route as route name when a selected node had been set as the front
Issue : Fix Varbase Welcome message not showing up after install compilation after adding and enabling moderation sidebar on the homepage
The composer plugin will not allow to apply it if it was committed.
This effectively means that you will get the latest version of the code from an issue, but you can't lock the patch file to a previous state, ignoring newer commits, until is fixed. So, it brings a security risk because any new commit to the issue's branch will be automatically deployed to your repo via the next "composer install" launch and can harm your project!