Worklog for task "Inventory of the current Ruby website"

Initial Technical Inventory of the Legacy Site

Initial documentation on the current implementation of bizneshelper.ru has been received.

Confirmed Stack

• Ruby on Rails 3.2.21 — legacy framework version.
• Ruby is not explicitly pinned; a compatible range of older Ruby versions is assumed for the project, roughly 1.9.3–2.2.x. For local reproduction, Ruby 2.2.10 seems like a reasonable starting point, but compatibility must be confirmed by actual execution.
• MySQL via mysql2 ~> 0.3.11.
• Bundler 1.15.4.
• A separate Solr environment is used for full-text search via sunspot_rails / sunspot_solr.

Key Dependencies

• devise — authentication, including administrative access.
• ckeditor — content editing.
• paperclip ~> 3.0 — handling uploaded files and images.
• friendly_id ~> 4.0.9 — human-readable URLs; critical for analyzing current routes and preserving URLs during migration.
• sunspot_rails, sunspot_solr — search; Solr will be required to fully reproduce legacy behavior.
• omniauth and social media providers — historical OAuth scenarios; the relevance of each provider must be checked individually.
• will_paginate, simple_form — pagination and forms.

Data and File Structure

• db/ contains 77 migrations, schema.rb, and seeds.rb; this is an important source for restoring the actual data model and its development history.
• files/ contains about 1,320 items; this directory must be mapped separately against Paperclip models and public media URLs.
• public_html/ contains static assets that must be distinguished from Rails-generated pages when preparing the migration map.
• solr/ contains search configuration and must be accounted for when inventorying search functionality.

Public Features

• The admin interface is available at /admin and uses Devise.
• The default locale is Russian (config.i18n.default_locale = :ru).

Major Technical Risks

1. The stack is significantly outdated, so running it locally on a modern system may require a separate legacy environment or containerization.
2. therubyracer / libv8 are potentially problematic when building on modern OSs.
3. mysql2 ~> 0.3.11 may be incompatible with current MySQL client libraries without additional measures.
4. Full reproduction of search will require Solr; without it, the site may boot, but one of the user scenarios will be incomplete.
5. friendly_id must be investigated before designing haih-cms routes, as current slugs and URL rules may be part of accumulated SEO value.
6. Paperclip and the files/ directory require separate verification: we need to understand the path scheme, model bindings, and the proportion of actually used files.
7. OAuth providers belong to legacy integrations; some of them may be non-functional or unnecessary in the new version, so they should not be automatically migrated as mandatory functionality.

What to Check Next

• The actual Ruby version via lock/config/deploy files or a successful local boot.
• Gemfile.lock and exact versions of all gems.
• schema.rb and Rails models: composition of entities, associations, and Paperclip attachment fields.
• routes.rb: actual public routes, /admin, friendly_id, and legacy redirects.
• Controllers and views: actual types of public pages.
• The relationship between files in files/ and DB records.
• The use of Solr in user scenarios.
• The actual relevance of OAuth and other external integrations.

Conclusion

The project is a classic Rails 3.2 legacy monolith with separate subsystems for file storage and Solr search. For migration to haih-cms, it is critical to first reproduce the current data model, routes, and media associations, and then migrate content and functionality. Attempting to treat the site merely as a set of HTML pages will result in the loss of a significant portion of the legacy system's logic.