Working with image toolkits it seems it would be easier to implement toolkits as modules, and leverage the existing module system for dynamic includes.

replacing the file_scan_directory with a module_invoke_all in image_get_available_toolkits.
updating the gd_... namespace to image_gd namespace
adding an image_check_settings function that call the toolkit specific check settings function.

This would allow people to implement custom image toolkits with customized crop and scale functions for their sites with core image.inc hacks.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Stefan Nagtegaal’s picture

Dopry, are you planning to work on this?

*subscribe*

dopry’s picture

unless you want to...

Stefan Nagtegaal’s picture

I would love to, but I have no idea what would be the best way to get this in..
If you could make some concept patch. I'll build further upon that.

Stefan Nagtegaal’s picture

Documentation about the mentioned function which should be used:
[14:11] Steef: module_invoke?
[14:11] Druplicon: usage module_invoke($module, $hook, $args) - see http://api.drupal.org/api/head/function/module_invoke

[14:11] Steef: module_invoke_all?
[14:11] Druplicon: module_invoke_all is usage module_invoke_all() - see http://api.drupal.org/api/head/function/module_invoke_all

[14:11] Steef: file_scan_directory?
[14:11] Druplicon: file_scan_directory is usage file_scan_directory($dir, $mask, $nomask = array('.', '..', 'CVS'), $callback = 0, $recurse = TRUE, $key = 'filename', $min_depth = 0, $depth = 0) - see http://api.drupal.org/api/head/function/file_scan_directory

Stefan Nagtegaal’s picture

FileSize
233.32 KB

Okay, I'm on this and it's pretty much working..
A lot of debug code to remove still, but we are getting there!

I'll post some screenshots for anyone who's interested in this..

---
Attached screenshots is the Toolkit selection page, as it is currently implemented. Only now it's using fieldsets to be consistent with the rest of drupal.. It directly shows the settings for the current selected image toolkit..

Stefan Nagtegaal’s picture

FileSize
230.72 KB

Here we choose to use imagemagick as our toolkit (which is a module now!).
The imagemagick.module isn't having settings (yet)..

Stefan Nagtegaal’s picture

FileSize
212.64 KB

Remember we have set imagemagick as our default toolkit?
When we do not disable the module, and simply delete it from our modules, the image api automatically falls back to GD support. (and shows it's settings directly!)

drewish’s picture

how about a patch?

Stefan Nagtegaal’s picture

Title: Update image toolkits to be implemented as modules. » Improve image-api: Image toolkits should be implemented as modules.
Status: Active » Needs review
FileSize
9.51 KB

Well, here we go..

This patch does the following:
- toolkits are modules now;
- the idea is to have a gd.module in core, which is enabled by default;
- people could use imagemagick.module or netpbm.module as a replcement for the gd.module. They can simply put the new modules is 'sites/modules/$toolkit/$toolkit.module', no fiddling around in includes/ anymore;
- i removed all the gd specific code from image.inc to gd.module, which makes image.inc a reall API and is much cleaner to extend;
- I removed a lot of code which wasn't used, or did not make sense;
- I made the administration part (where you select your toolkit and set your preferences for it) more consistent with the rest of Drupal;

What still needs to be done in this patch;
- upgrade path;
- find out where our default enabled modules get set;

What needs to be done (in separate followup patches);
- the gd.module could use some cleanup as I simply copied all the gd specific functions to the gd.module. I did make some notes in there to make sure I/we don't forget about it;
- write the imagemagick.module, based on the image.imagemagick.inc;

How to test?
- simply apply the patch to your drupal install.
- download the gd.module and gd.info file (from the next issue folowup), and put it in the modules/gd directory or sites/(all|default)/modules/gd;
- goto 'Administer' >> 'Site building' >> 'Modules' and enable it in the 'Image processing toolkits' fieldset;
- Try uploading and resizing images!

Stefan Nagtegaal’s picture

FileSize
138 bytes

Attached is the gd.info file which should live under 'modules/gd' or 'sites/(all|default)/modules/gd'.

NOTE: Rename gd.info.txt to gd.info

Stefan Nagtegaal’s picture

FileSize
3.5 KB

Attached is the gd.module file which should live under 'modules/gd' or 'sites/(all|default)/modules/gd'.

NOTE: Rename gd.module.txt to gd.module

dikini’s picture

The approach makes includes/ better and slimmer. Makes advanced theming more flexible.

Stefan Nagtegaal’s picture

FileSize
10.94 KB

New patch, which adds:
- the upgrade path;
- and made gd.module enabled by default with new installations;

You still have to manually download and rename the gd.info and gd.module files.

Place them inside 'modules/gd'.

(untill I found out how I can do that all automagically in this patch)

Stefan Nagtegaal’s picture

FileSize
3.47 KB

There was a bug inside the gd.module, which didnt allow you to resize/crop images.

Stefan Nagtegaal’s picture

Assigned: dopry » Stefan Nagtegaal

To test:
- grab the patch, place it inside drupal root and apply it using: 'patch -p0 imageapi.patch';
- make a new directory under 'modules/' called 'gd';
- grab the gd.info and the gd.module files, and place them in the new created 'gd' directory;
- rename the files to gd.info and gd.module!

That's it! have fun!

drewish’s picture

FileSize
15.74 KB

how's this look? it uses a hook_image_toolkit. it cleans up a lot of the gd.module stuff.

chx’s picture

Status: Needs review » Needs work
FileSize
16.33 KB

Code style and doxygen fixes, no code changes. I am pretty OK with where this goes, though not requiring gd module would be great...

Stefan Nagtegaal’s picture

Status: Needs work » Needs review
FileSize
16.86 KB

As Karoly stated, the gd.module shouldn't be enabled by default and not required during install.

So, updated patch which addresses:
- made gd2.module optional;
- added gd2.install which checks for a PHP installation with gd compiled;
- made system_image_toolkit_settings() smarter so it doesn't display unnecessary options;

dikini’s picture

It is much cleaner now. I like the api - toolkit split. The old behaviour is preserved and the gd.module is optional.

drewish’s picture

Stefan Nagtegaal, I don't know what it is but all your patches that add files end up breaking my patch program (both on Windows and FreeBSD):

$ patch -p0 < imagetoolkits.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|=== added directory 'modules/gd'
|=== added file 'modules/gd/gd.info'
|--- modules/gd/gd.info 1970-01-01 00:00:00 +0000
|+++ modules/gd/gd.info 2007-06-07 12:22:26 +0000
--------------------------
Patching file modules/gd/gd.info using Plan A...
patch: **** malformed patch at line 10:

$ patch --version
Patch version 2.1

I tried chx's patch and it worked fine. Eyeballing the two doesn't make it clear what the difference is.

The current patch looks good, the only thing I'm not happy with is the way we get the settings. Having a _setting() hook works but is a bit wonky. We could just let the image toolkit modules form alter the /admin/settings/image-toolkit form... I'm sort of thinking it might be better for the toolkits to each have a menu hook and put themselves on tabs under /admin/settings/image-toolkit, i.e. /admin/settings/image-toolkit/gd and /admin/settings/image-toolkit/imagemagick.

Thoughts?

Stefan Nagtegaal’s picture

I'm not sure about it.
The tabs are used for 'tasks', and a toolkit is not a task, configuring it is.. But looking through drupal we would create another inconsistency.

How about this:
We have an overview tab (called "overview") at 'admin/settings/image-toolkit' that displays a table:
[Toolkit] [Default] [Operations]

You could pick the default toolkit, with using radio buttons when. Operations has a 'configure'-link that brings you to the toolkits settings.

And we would have a configure tab (called "configure"), which has $toolkits_available as secondary tabs.

Advantages:
- it allows you to setup a new toolkit once the old one is still in use;
- it's consistent with the rest of drupals interface (filter/block/system/locale.modules all implement this kind of layout.)

Just some thoughts...

drewish’s picture

FileSize
4.62 KB

for reference here's an imagemagic toolkit using this api

drewish’s picture

FileSize
26.79 KB

so i moved the settings into a hook_form_alter and it work pretty well but it gives you validation errors if you submit the form again after changing the toolkit selection. i'm sure it's something simple i'm missing. i'll try to get one of the fapi gurus to look at it.

i fixed one bug in the rotate, there was a bg_color setting that wasn't being passed in correct so i added that to image_gd_rotate() and got it working for both gd and imagemagick.

i included the imagemagick toolkit in this patch. i don't really expect it to get into core but it's handy for testing.

drewish’s picture

FileSize
25.71 KB

I talked to Steef on IRC and he convinced me that the way I was doing the settings wasn't good. I tried using the plan he outlined with "List" being the default tab under "Image Toolkit" and "Configure" with sub tabs for each toolkit.

settings/image-toolkit
         image-toolkit/list
         image-toolkit/configure    <-- problem is here
         image-toolkit/configure/gd
         image-toolkit/configure/imagemagick

I defined a hook_menu for each toolkit to add itself in below configure and make itself the default tab if it was the selected toolkit. That worked well until you tried to visit the "Configure" tab. It needs to have the current toolkit's callback info but since the modules define their own settings (heck, they may not even have any settings) the system.module can't put them into the menu.

My fall back plan was to just to have each toolkit define its own settings page: admin/settings/gd or admin/settings/imagemagick. It was the simplest way of doing it.

drewish’s picture

FileSize
27.94 KB

Okay, so if we require every image toolkit to have a modulename_settings_form() function that returns a form, Steef's menus work. For the time being I've left the hook_menus in the imagetoolkit modules.

I also did a bunch of cleanup on the PHPDocs so that Dries wouldn't have any low hanging fruit when reviewing the patch ;)

jvandyk’s picture

FileSize
18.22 KB

After creating a new site I went to Administer - Site configuration - Image toolkit and was told "There are no image toolkit modules enabled." Either the GD module should be automatically enabled or there needs to be a link here to the modules page.

So I enable the GD module and return to Administer - Site configuration - Image toolkit. Well, there's a single selected radio button for "Built-in GD2 image processing support." If I can't change anything, the page is unneeded. Especially since, after enabling the GD module I see Administer - Site configuration - GD image toolkit.

Maybe a better approach is to have the GD and Imagemagick modules check at install whether another toolkit is enabled, and only allow one enabled at a time.

imagemagick.module found my installation and ran -version successfully.

Removed _imagemagick_check_path() just use is_file() directly instead.

Cleaned up comments and variable initialization.

drewish’s picture

FileSize
28.21 KB

jvandyk, your patch lost the new files. so i just made the changes you described to my copy.
i removed the hook_menu that you weren't into.
cleaned up the UI when there are 0 and 1 toolkits enabled.
also replaced _imagemagick_check_path() with is_file().

webchick’s picture

I should probably withold comment until I actually test this patch, but most of John's statements have me thinking, "Um. Do modules really make sense for this?"

If you can only have one or the other installed at a time (gd, imagemagick, or netpbm) it seems that this fits much better into our database-XX.inc motif than it does a module motif. I asked drewish about this, and he brought up the point that .inc files can't have hook_menu for settings pages, or hook_requirements for checking run-time/install-time requirements, and they wouldn't work with update status module, for instance. But you can work around the lack of hooks with system.module (which I assume is how this was done in the past), and you don't need update status module integration if you add image-imagemagick.inc to core (and maybe image-netpbm.inc). That seems like a much bigger gain with far fewer UI headaches, and I assume that can be done relatively easily from the imagemagick.module?

webchick’s picture

And what happened to http://drupal.org/node/148346 ? :( That was such a nice, simple approach. :(

drewish’s picture

webchick, if we could get imagemagick (and possibly a netpbm) into core i'd be happy to move it back to the .inc model (as in #148346). if it doesn't look like that would be committed to core then i think moving it to modules is a much more contrib friendly way to go.

drewish’s picture

FileSize
28.34 KB

image_get_available_toolkits() now parses the .info file for module info. the only bug at this point is the config menu after you disable or unselect a toolkit.

Stefan Nagtegaal’s picture

Drewish, what is the way to replicate the bug?
I'm reviewing/checking your patch atm..

drewish’s picture

goto the configure tab after changing the selected toolkit, or maybe disabling the module, i can't remember which.

drewish’s picture

what it boils down to is are toolkits for imagemagick and netpbm going to be commited to core? if not, then it needs to be much easier for image toolkits to be in contrib.

right now users have to copy a .inc file from the image module into their includes directory. once they've done this there's no obvious way to tell if a new .inc file has been released that fixes a bug. if the toolkit was a module the user could use the update_status module to find out about updates. the toolkit could also do a better job of displaying requirements with hook_requirements.

dopry’s picture

FileSize
20.44 KB

@webchick:
The reasons I like the hook_toolkit approach to the image toolkits are

  1. implement slight customized toolkits for individual sites.
  2. leverage the module system for dynamic includes.
  3. requirements, both for modules requiring specific toolkits and the toolkit modules themselves.
  4. leveraging multiple toolkits at once.

The attached patch makes it a little easier for module developers to leverage multiple toolkits at once.

Stefan Nagtegaal’s picture

The patch from dopry works very well, and is very nice..

Is there anyone else who could review this patch again, and could set it RTBC?

hunmonk’s picture

sub

Stefan Nagtegaal’s picture

Okay, I tested this quite intensive and did no come up with any problems except that doprys patch includes the settings.php changes. Rerolling the patch in a minute..

Stefan Nagtegaal’s picture

FileSize
23.93 KB

- Removed settings.php changes;
- Added the gd module files;

hunmonk’s picture

Status: Needs review » Needs work

i can't apply the patch:

505 colossus$~/bzr/image_toolkits: patch --dry-run -p0 < ~/Desktop/image-toolkits.patch
patching file includes/image.inc
patching file modules/system/system.module
patching file modules/gd/gd.info
patching file modules/gd/gd.install
patching file modules/gd/gd.module
patch unexpectedly ends in middle of line
patch: **** malformed patch at line 709:

dopry’s picture

Status: Needs work » Needs review
FileSize
23.97 KB

Here is a re-rolled version of the patch.

drewish’s picture

FileSize
5.53 KB

i'm attaching a patch with the imagemagick toolkit. it's useful for testing to see how the patch works with multiple toolkits.

drewish’s picture

Status: Needs review » Reviewed & tested by the community

i've tested the re-roll dopry posted on #41 and it looks good to me. since it's the same thing that Stefan Nagtegaal has tested, RTBC.

Stefan Nagtegaal’s picture

In all, this opens up tons of new possibilities for Image handling and even more for the flexibility of it.

IMO we should not ship Drupal 6 without this!

mdlueck’s picture

I vote to get this even into an update for Drupal 5.

We host currently with 1&1, and also do development work for clients with other providers. Some interface needs to be supplied to look in an alternate path specified to locate the image toolkit binaries. Gallery does this when you enable ImageMagick, and we have Gallery correctly working with ImageMagick.

There seems to be much FUD about getting Drupal 5 to use ImageMagick. Clean install of Drupal 5 gives no indication of what tool kits Drupal even looks for... just "none found, so using GD." It seems module Image must be installed, a file copied to the /includes dir. That being done, then the system's bin directory is where the Image module expects to find the toolkit - no possibility to specify an alternate path.

Summary - Image Toolkit in Drupal 5 seems buggy at best. I would certainly hope that fixing this in Drupal 6 would not be optional!

drewish’s picture

The patch on #41 still applies (one hunk has a one line offset)...

drewish’s picture

FileSize
19.78 KB

re-roll to cut down on fuzz

Stefan Nagtegaal’s picture

Assigned: Stefan Nagtegaal » Unassigned

Unassigning...

wundo’s picture

* subscribing *

Dries’s picture

Version: 6.x-dev » 7.x-dev

Moving this to D7.

Stefan Nagtegaal’s picture

Dries, it would be nice if you could tell us what you think about the patch so we could improve it, or keep it up with head so you can commit it as soon as D7 opens up for development.

We (and I in particular ;-)) definatly need an easier and more flexible way to handle images.

Perhaps you can shed a light over the patch and tell us your opinion.

Zothos’s picture

* subscribing *

get this thing in. Would be a great improvement :)

sun’s picture

Status: Reviewed & tested by the community » Postponed
Stefan Nagtegaal’s picture

Status: Postponed » Needs review
FileSize
17.13 KB

Okay, Drupal 6 is out.. Let's get this sucker in...

And an updated patch for HEAD of today, not seriously tested but should work (or very simple to fix)..
Please test the patch and leave your comments! :-)

drewish’s picture

Status: Needs review » Needs work

i can't seem to figure out how to get CVS to let me add the modules/gd directory to the patch so i can't really re-roll. so here's my list of changes that need to be made:

  • need to remove image.gd.inc
  • color.install and gd.install both have the check for the GD library:
    • remove it from color.install.
    • mark color.module as dependent on gd.module
    • update the default profile to enable the gd module by default.
    • remove color.install.
  • system_menu() needs to check that image_get_toolkit() returns a non-FALSE value or else you end up with admin/settings/image-toolkit/config trying to call drupal_get_form('_settings_form') which doesn't work.
  • image_get_available_toolkits() should return the module's hook_requirements() status. when we build the menu items for the toolkit config forms we should list all toolkits (in case the requirements are failing because of an un-configured setting). in system_image_toolkit_settings() we should list all the active toolkits but disable the radio buttons for those with failing requirements (with an explanation of which requirement has not been met).
Stefan Nagtegaal’s picture

@Drewish: Have a look at: http://drupal.org/patch/create and then especially from the header "Adding/deleting files"..
It works that way, it's exactly how I am doing it...

I would really appreciate your help on this, as time is not my best friend at the moment...

drewish’s picture

Stefan Nagtegaal, I did follow those directions but they didn't work. on that page it says that the technique does not work for creating directories... what are you doing differently?

Stefan Nagtegaal’s picture

Hmmm... strange.. I just did hat it says...
Ehm... Can you provide separate patches for core, and attach the module file?
I'll make a patch of it so it could be reviewed/tested and (hopefully and eventually) applied..

drewish’s picture

so here's a patch that addresses the issues i raised in #55. it adds requirements checking to image_get_available_toolkits() but
system_image_toolkit_settings() is a hack right now. i couldn't think of a clean way to distinguish between the toolkits that have okay requirements and those that don't.

because of my above mentioned cvs problem, i split this into two patches.

Stefan Nagtegaal’s picture

@drewish: Have a look at how dopy implemented the imageapi_get_available_toolkits() in his imageapi.module. That one looks clean and not as hackish as this implementation..

this is getting there, I'm feeling it... :-)

drewish’s picture

Stefan Nagtegaal, not a very helpful comment. i just checked and it looks like the imageapi code was identical to what the function looked like before i added requirements checking on. what's "hackish" about my approach? criticism is fine as long as it's constructive.

Jaza’s picture

Version: 7.x-dev » 8.x-dev

Moving.

sun’s picture

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

Issue summary: View changes
Status: Needs work » Postponed (maintainer needs more info)

Wonder if this is still a desired feature?

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.