Prepopulate misbehaving

[designermonkey]

Given the URL https://domain.com/publish/section-name/new/?prepopulate[451]=regexp%3A%20jrp, the field in question is populated with regexp: jrp.

Expected value is jrp.

[nitriques]

I would ping @michael-e on this one...

But John, do you know where the %3A character comes from ?

[brendo]

I don't believe we do any handling to strip the filtering prefixes from data before handing it to a field currently, so this is the expected behaviour at the moment from me. It's a good idea though, I can't see any reason why the field would need to know filtering information when prepopulating.

[michael-e]

I agree with @brendo. It's expected behaviour, but it could be improved.

[cylkee]

Adding my two pence here, as directed by @nitriques.

I'm trying to create contextual admin links from the front-end to the back-end UI for logged-in authors. So far so good with basic section links and filtering. However, pre-populating SBLs doesn't appear to accept the field handle and there seems no easy way to know the field's ID e.g.

/symphony/publish/test/new/?prepopulate[11]=222 works as expected

/symphony/publish/test/new/?prepopulate[selector]=222 does not populate SBL

Incidentally, /symphony/publish/test/new/?prepopulate[11]=item-handle does not populate SBL

If pre-populating by field handle string turns out to be a big headache, please could each field's ID be passed to the XML.

[nitriques]

Funny or not, mod_sec prevents me from using regexp: in the url. I think it would be wise to change this to something else.

@cylkee

If pre-populating by field handle string turns out to be a big headache

Yes it is. It could be enabled, but not a priority sadly. If you want to send a PR, I'll gladly help you test it.

please could each field's ID be passed to the XML.

That's doable too if you want to poke at it!