#12571 , #12573 Support of distinct search-typename in WMS layers and way to edit urls of layers

[Binabh]

Description

This PR covers two functionalities of letting user change layer URL and WFS linked service for WMS Layers

Please check if the PR fulfills these requirements

• The commit message follows our guidelines: https://github.com/geosolutions-it/MapStore2/blob/master/CONTRIBUTING.md
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

What kind of change does this PR introduce? (check one with "x", remove the others)

• Feature

Issue

What is the current behavior?
#12571 #12573

What is the new behavior?
User is able to change URLs and WFS linked service and it properly reflects on network calls.

Breaking change

Does this PR introduce a breaking change? (check one with "x", remove the other)

• Yes, and I documented them in migration notes
• No

[offtherailz]

Hi, some feedback from the UI point of view:

• Validation is missing on the layer URL and on the WFS URL/typeName fields (currently only the layer name is validated). The layer URL should go through the same validation as the layer name, and the WFS fields as well — the typeName could be validated with a DescribeFeatureType call, which would also give us the field refresh (see below). Note that with no validation an empty value is accepted: since getSearchUrl falls back to the layer URL, an empty WFS URL silently sends WFS requests to the WMS endpoint. GeoServer answers those on /wms too, so nothing looks broken, but it breaks as soon as the WFS lives on a different endpoint or host.
• Fields stay saved once they have been downloaded, even if the layer changed completely: they are not reloaded when the typeName (or the layer name) changes, and the stale list is persisted on the layer. This is a pre-existing behaviour that may affect bbox and other items too, so it may be worth a separate issue. On reload I would keep the merge as it is: fields with the same name keep their customizations, fields that no longer exist disappear, and the dedicated button is there for whoever wants to drop the customizations — otherwise renaming a layer or changing an attribute means rewriting everything.
• When you turn the WFS panel off and on again, the typeName is recreated with the layer name while the URL is left empty. Both are actually rewritten from defaults, so a custom typeName is silently replaced by the layer name. Could we use the same DescribeLayer request to retrieve the WFS URL (and typeName) when re-enabling the panel? Please note that the current merge keeps the existing search on top of the detected one, so it has to be reversed for an explicit user action, and we should handle servers that do not support DescribeLayer by simply leaving the field empty.

[Binabh]

@offtherailz Thank you for your feedback. As Per your suggestion I have added validation for url, searchUrl and typename and have also appropriately populated values from DescribeLayer. I have also added tests and also verified manually. Let me know if any further improvements are needed.
Thank You!

[offtherailz]

WMS

• I noticed this regression of layer name for WFS layers

Screencast.from.2026-08-26.16-51-34.webm

WFS link service editing looks to work fine

WFS

• Type name is not editable, only URL... this is a little inconsistent. IT was indicated in #12571 comment:

Same capability for native WFS layers (type: wfs): editing layer.url and typeName on the WFS layer's General tab

[Binabh]

@offtherailz Thank You for your review. The issue of Type Name not editable is addressed by another PR(already merged) and also available here as this has already synced with master. Instead of Type Name Another PR uses Name as other layer types also use that.

Also, the regression when editing WMS name is now solved. (video attached below)

Screen.Recording.2026-08-27.at.17.29.42.mov

I have re-tested that other regression and feed backs reported on #12787 are not re-introduced while solving merge conflict.
Please let me know if any further changes are required. Thank You!

[offtherailz]

No time to test for me, but code changes look good. I'd suggest to widly test this features on dev.

[tdipisa]

@offtherailz thanks. I'm going to merge, @ElenaGallo will verify in DEV shortly.