SHS-6056: Allow external access to Localist API methods

[codechefmarc]

READY FOR REVIEW

Summary

• Changes some of the methods in the LocalistUrlWidget so they are public to be able to be accessed from outside the widget and adds a $base_url parameter that can be passed by the external calls.
• This work was needed for SHS-6056: Dashboard: Importer block: Events SU-HSDO/suhumsci#1755 which needed to provide Localist importer information into the dashboard. We felt that we wanted to reuse code where possible.
• For future work - it would be suggested to move all the Localist specific methods into their own service which could be called by the widget and by other services like the dashboard block.

Review By (Date)

3/5/2025

Criticality

• How critical is this PR on a 1-10 scale? Also see Severity Assessment.
• E.g., it affects one site, or every site and product?
• Affects every site that uses the LocalistUrlWidget to set Localist migrations.

Urgency

• High

Review Tasks

Setup tasks and/or behavior to test

1. Visit /admin/structure/migrate/localist-events
2. Verify that the Departments/Groups, Venues, Audience, Subject, and Event Types all have data coming in from Localist
3. Set some values and save the config page
4. Verify that the values save
5. Additional testing over on the platform PR: SHS-6056: Dashboard: Importer block: Events SU-HSDO/suhumsci#1755

Site Configuration Sync

• Is there a config:export in this PR that changes the config sync directory?
• No

Front End Validation

• Design is approved by @ user?
• HTML validation: Is the markup using the appropriate semantic tags and passes validation? Or, QA request ticket created?
• Cross-browser testing: Has been performed? Or, QA request ticket created?
• Automated accessibility: Scans performed? Or, QA request ticket created?
• Manual accessibility: Manually tested? Or, QA request ticket created?

Backend / Functional Validation

Code

• Are the naming conventions following our standards?
• Does the code have sufficient inline comments?
• Is there anything in this code that would be hidden or hard to discover through the UI?
• Are there any code smells?
• Are tests provided? eg (unit, behat, or codeception)

Code security

• Are all forms properly sanitized?
• Any obvious security flaws or new areas for attack?

General

• Is there anything included in this PR that is not related to the problem it is trying to solve?
• Is the approach to the problem appropriate?

Affected Projects or Products

• Does this PR impact any particular projects, products, or modules?

Associated Issues and/or People

• JIRA ticket(s)
• Other PRs
• Any other contextual information that might be helpful (e.g., description of a bug that this PR fixes, new functionality that it adds, etc.)
• Anyone who should be notified? (@mention them here)

Resources

• AMP Tool
• Accessibility Manual Test Script
• HTML Validator
• Browserstack and link to Browserstack Credentials

[cienvaras]

@joegl Updated this PR as requested. No issues, Drupal 10 is still supported. I wasn't able to assign the PR, because I don't have permissions. Let me know if you have questions, Thanks!

cc. @pookmish

[joegl]

Got it, thanks @cienvaras

[pookmish]

Field widgets aren't intended to be used like this. They have a dedicated purpose and that does not work with this approach.

If you'd like to perform something like this, extract the functionality out into a service. then the service can be used inside the field widget.

[joegl]

@cienvaras See Mike's comment above