Task: Re-implement forms and current public integrations from scratch
Re-implement forms and current public integrations from scratch
Do not migrate legacy form implementations literally; re-implement only the relevant user scenarios on haih-cms.
Objective
Implement on the new platform only those forms and public integration scenarios that are required by the new website.
What to Do
- Based on the inventory results, determine the actually needed forms and user actions.
- Do not migrate legacy form code, Devise/OAuth, or other integrations automatically just because they exist in the old project.
- For each required scenario, design a new implementation using haih-cms and the current stack.
- Set up validation, error messages, and successful submission confirmations.
- Check protection against obvious spam and duplicate submissions.
- Connect external integrations only when there is a confirmed necessity.
Result
The new website contains an up-to-date set of forms and public integrations without dependency on legacy code.
Definition of Done
- All necessary user scenarios are implemented.
- Outdated OAuth and other legacy integrations are not migrated automatically.
- Forms operate independently of the Ruby application.
- Sensitive parameters are not recorded in the public task.
Ворклоги
Change in Approach to Forms and Integrations
The legacy implementation of forms, OAuth, and external integrations is not being migrated automatically. Only the user scenarios that are actually needed will be re-implemented on the new site.
This makes it possible to eliminate dependence on old Rails gems and outdated providers, and avoids carrying over functionality merely for the sake of compatibility.
Legacy Defect: Social Authorization in Feedback Form Does Not Work
The feedback form interface offers users four social authorization options:
- Google+ (
/auth/gplus) - Vkontakte (
/auth/vkontakte) - Twitter (
/auth/twitter) - Facebook (
/auth/facebook)
In fact, none of these scenarios currently work.
Why It Matters
This is another clear example of legacy functionality degradation: the interface continues to promise users features that technically no longer exist or are unsupported. To a visitor, this looks like a broken website, and for maintenance teams, it creates a false scope of functionality that has to be investigated separately.
It is especially noteworthy that Google+ is present — a service that was shut down for consumer use long ago. The very fact that such an item remains in the current interface shows how easily external integrations turn into technical debt if they are not reviewed regularly.
Conclusion for the New Version
Social authorization should not be migrated just because it was present in the old interface. For haih-cms, it is necessary to redefine whether authorization is needed by the user at all, and if so — to implement only relevant and truly supported scenarios.
It is better to have a simple, working feedback path than a set of visually attractive but non-working login methods.
Practical Impact on Migration
Legacy OAuth routes should be treated as historical functionality rather than a mandatory requirement for the new implementation. Their presence must be accounted for during the inventory process, but they should not be reproduced without confirmed user value.