State of the art about CTools plugins

I've searched various backdrop issue queues about port of Drupal CTools plugins system, but found interesting pieces only either two years old, or tagged 2.x ...
I've seen the "Form Element Layout" approach, which is basically recreating a plugin API, and the "Adressfield" approach, which is hardcoding everything (which I find a lot cleaner, but requires a lot of typo...)

What's the "recommended" way to deal with plugins, now ?

FYI, I'm looking at the port of the drupal "geocoder" project, which, by the way, could provide "geocode from addressfield"... Given that "geophp", "geofield", and "leaflet" run perfectly in backdrop whith just "backdrop = 1.x" added to the info file, we could have a nice backdrop mapping solution for this (I whish you happy) new year !

[docwilmot]

Hi @gifad I'm not an expert, but @quicksketch gave this advice on dealing with CTools plugins. Hope that helps. Happy New Year to you too!

[jenlampton]

Hi @gifad I just ported two modules in the last two weeks that had ctools integration, addressfield and flexslider so I've had some experience with ctools -> backdrop conversions.

Addressfield had a style plugin, and that was really easy to map to an info hook and callback functions. I like that custom hard-coded approach because it's clean and simple and matches the rest of Backdrop's code structure.

Flexslider is a little more complicated (and I'm not sure flexsider_views is currently working, since it depends on a core views patch which is still failing tests). Flexslider had exportable plugins, and when moving those over to Backdrop you need to build a whole UI for your exportable things. This is certainly more work, but I'm hoping that we'll end up with better user interfaces for it.

I half expect that a contrib UI-builder might emerge too, but with the exportable part of exportables being in core for Backdrop, the necessity for an exportable "plugin" is much lower.

I am planning on writing up a several-part blog series on ctools plugin conversion, but they aren't on the official backdrop blog-schedule yet. Perhaps those should be prioritized, and/or moved over to my own blog to get them out sooner.

Also, thank you for tackling geocoder! I will be using that module too, here in the coming months :)

Thank you both for your replies, much appreciated; I will report next week, I hope..

I've made an initial port of geocoder, on the addressfield model, and it was even easyer...
You can review it at https://github.com/gifad/backdrop-geokit/tree/master/modules/geocoder, and even give it a try !
I ported only the exif and google plugins, which I could test, successfully, with geolocated images, and addresses from your module.
While I was at it, I also ported and uploaded a set of geo* modules, to produce the nice leaflet maps I'm used to...
Enjoy !

[jenlampton]

This is fantastic! :) I'll take them for a spin on my site in the next week or two :) Any chance of moving them over into the contrib space before then?

No, not likely, see #125;
@earthday47 showed some interest for the project, but this was 3 weeks ago...
The various modules and third party libraries of my 'kit' are very closely related, and although it works far better than Backdrop/CKEditor integration, it's one level higher in complexity, and the packaging and/or documentation are critical issues !

[earthday47]

Sorry about dropping off, I got pulled to another project. J can at least get them imported into Backdrop contribute space and development can continue ...

[earthday47]

@gifad @jenlampton backdrop-ops/contrib#125 (comment)
Playtime has officially begun ;)

[earthday47]

links to contrib projects

Geocoder (https://github.com/backdrop-contrib/geocoder)
Geofield (https://github.com/backdrop-contrib/geofield)
geoPHP (https://github.com/backdrop-contrib/geophp)
Leaflet (https://github.com/backdrop-contrib/leaflet)

[MrHaroldA]

Form Element Layout has a rather "bad" implementation of its required CTools functions; it just copy/pasted the functions without changing the function names.

https://github.com/backdrop-contrib/form-element-layout/blob/1.x-1.0.0/fel.module#L370

This will collide with any other module that implements it in the same, bad way.

Should Backdrop provide some (more) drop-in replacements for the most used CTools functions by (ported) contrib modules?

[Graham-72]

I would like there to be some sort of central register of the CTools functions that have been used in Backdrop contrib modules, perhaps in backdrop-ops/contrib. Then we can share effort and avoid duplication.

Perhaps also a similar register for entity functions? I have had to add some in to one or two contrib modules, though they need to be checked in the light of additions to core over recent months.