Drupal 11 Support

Hello and thanks for this beautiful module, working as a bridge for two great free software projects.

Edited with the help of an LLM.

Problem/Motivation

The only release is 7.x-1.4 (2015). Drupal 7 reached end of life in January 2025, and GeoServer 3.0 (Spring 7, Jakarta EE, Java 17/21) is now the stable line, with 3.0.2 released in October 2026. There is no way to connect a supported Drupal site to GeoServer with this module.

The 7.x code cannot be upgraded with Rector or Upgrade Status alone. It depends on APIs that no longer exist: CTools exportables and plugin types, the OpenLayers 7.x-2.x API, variable_*(), db_query(), raw cURL, Features hooks, a Drush 5 command file and the PostGIS 7.x module.

What 7.x-1.x does today:

• Talks to the GeoServer REST API (XML, JSON, SLD payloads).
• Defines layers and SLD styles in Drupal and pushes them to GeoServer, with a same / different / not found status check.
• Creates the workspace and a PostGIS datastore pointing at the Drupal database.
• Generates read layer X / write layer X permissions.
• Truncates GeoWebCache for the affected bounding box on node insert, update and delete.
• Logs Drupal users in to GeoServer with their Drupal credentials and keeps the session alive from cron.
• Exposes GeoServer layers as OpenLayers WMS, cached WMS and WFS layers.

On a client project we used a custom D9/D10 module that uploads spatial files from a file field to GeoServer through the REST Importer, stores the resulting layer names on the node and shows them as WMS layers on a Leaflet map. It is too project-specific to publish, but it covers use cases that are worth bringing into this project.

Steps to reproduce

Not applicable (feature request). 7.x-1.x cannot be installed on Drupal 10 or 11.

Proposed resolution

A new 2.0.x branch for Drupal ^10.3 || ^11 and GeoServer 3.0.2 or later. GeoServer 2.x is not a target; it may work since the REST endpoints are the same, but it will not be tested.

Core module:

• Settings form and geoserver.settings config (URL, workspace, datastore). Credentials stay out of exported config (Key module or settings.php).
• A geoserver.client service on the core HTTP client with basic auth, replacing the cURL helpers and per-user cookie files.
• geoserver_layer and geoserver_style config entities replacing CTools exportables; saving or deleting one syncs GeoServer. Shipping them in config/install replaces the Features hooks.
• An attribute-based layer type plugin manager replacing the CTools layer_types plugin type.
• Per-layer permissions through permission_callbacks.
• GeoWebCache truncation for any content entity with a Geofield, using geoPHP for the bounding box.
• A Drush 13 geoserver:sync command replacing geoserver-configure.

Optional submodules:

• geoserver_importer: upload vector data (Shapefile ZIP, GeoPackage) from a configurable file field through the REST Importer, processed in a queue.
• geoserver_raster: large raster uploads (GeoTIFF, Cloud Optimized GeoTIFF) through a file field with resumable uploads (depends on File Resumable Upload). Files are stored in a directory shared with GeoServer and published as coverage stores by path, so multi-GB files are not sent over HTTP a second time.
• geoserver_leaflet: GeoServer layers (WMS, WMTS, WFS as GeoJSON) for the Leaflet module, replacing the OpenLayers 2 plugins.

Per-user authentication through OpenID Connect (replaces the 7.x login flow):

• Per-user login stays, but with Drupal as the OIDC identity provider (simple_oauth with its OpenID Connect support) and GeoServer as the client (the OIDC extension of GeoServer 3). GeoServer sees the real Drupal user without storing a copy of the password, and without the geoserver-sec-drupal extension, the cross-domain cookie workaround or the cron keep-alive.
• Drupal roles are exposed as a claim and mapped to GeoServer roles. The per-layer read/write permissions are synced to GeoServer data security rules, so GeoServer enforces them for every client.
• Administrative REST calls (layer, style and workspace sync) use a separate service account.
• Browser map requests rely on the GeoServer session, so GeoServer and Drupal should run under the same site (e.g. geo.example.com and www.example.com) to avoid third-party cookie blocking.

Kept from 7.x-1.x:

• Automatic creation of the PostGIS datastore, with cartaro as its default name, in recognition of the Cartaro team who built the original module. The name can be changed in the settings.

Remaining tasks

1. Agree on scope and branch name with the maintainers.
2. Scaffold 2.0.x: info file, composer.json, settings form, client service, GitLab CI.
3. Layer and style config entities, layer type plugins, sync logic.
4. Permissions, GeoWebCache truncation, Drush command.
5. geoserver_importer, geoserver_raster and geoserver_leaflet submodules.
6. Kernel tests with a mocked REST API; manual tests against GeoServer 3.0.2 with the Importer extension and a PostGIS datastore.
7. Follow-up: Migrate plugins for 7.x layers, styles and settings.

Work happens in the issue fork geoserver-3590500, branch 3590500-drupal-11-support.

User interface changes

The CTools Export UI is replaced by config entity list builders and forms under Configuration » Web services » GeoServer. Maps use Leaflet instead of OpenLayers.

API changes

The 7.x public functions (geoserver_get(), geoserver_post(), geoserver_layer_load(), geoserver_style_save() etc.) are replaced by the client service, config entity storage and the layer type plugin manager. 7.x layer type plugins need to be ported.

Data model changes

The geoserver_layers and geoserver_styles tables become config entities, and the geoserver_* variables become geoserver.settings. Whether geoserver_pk_metadata_table (primary key metadata for WFS-T inserts) is still needed will be decided during the port.

Best,
Orkut