Establishment of Ukrainian language

Development of a mass product creation module for OpenCart (ocStore 3.x) It is necessary to develop an administrative module for OpenCart / ocStore 3.x that automatically creates products from a pre-prepared folder structure with images.Main functionality: mass creation of products from selected folders; automatic retrieval of the product name from the folder name; automatic import of all images while preserving their order; selection of the destination category; mass assignment of selected product options; use of the existing SKU/Model generation module (if installed); support for JPG/JPEG and WebP formats; verification before creating products; error log only (successful operations do not need to be logged). The interface has already been fully designed and drawn. Attached to the project: detailed technical specifications; graphic interface layouts; after the project is published, a video with a detailed explanation of the module's logic will be added. Please review the attached materials carefully before responding. Development is required for OpenCart / ocStore 3.x using the system's standard mechanisms and with the possibility of further refinement.

Good day. I am looking for a developer for the TehnoVek / T-VEK project. It is necessary to create not just a beautiful landing page, but the first technical stage of the future online store. Project: TehnoVek / T-VEK Domain: tehnovek.com.ua Format: physical store + website + mini-catalog + future online store. Main direction: electric scooters, electric tricycles, electric bicycles, motorcycle equipment, ATVs, spare parts, accessories, service, delivery, credit/installment. Requirements: WordPress + WooCommerce. Main page as a landing page. Product catalog. Product categories. The first products must be entered as WooCommerce products, not as simple blocks. Application forms: select equipment; inquire about a product; credit / installment; delivery. Buttons for Telegram / Viber / WhatsApp. Hotline 0 800 108 100 in the header, footer, and key blocks of the site. Pages: electric scooters; electric tricycles; electric bicycles; motorcycle equipment and ATVs; spare parts and accessories; service and support; credit and installment; delivery in the region; delivery in Ukraine; physical store; warranty; contacts; blog. Basic SEO. Mobile adaptation. Fast loading. Integration of Google Analytics 4, Google Tag Manager, Meta Pixel, TikTok Pixel. Possibility of future integration with CRM. Possibility of future connection to Google Merchant Center. Possibility of a future AI consultant. Possibility of scaling into a full-fledged online store without a complete redesign. Important: the site can start as a landing page + mini-catalog, but it must be technically made so that in 3–6 months it can be expanded into a full online store. Please respond specifically to the points: Do you work with WordPress + WooCommerce? Can you create a landing page based on WooCommerce? Will the products be entered as WooCommerce products? Will it be possible to later add a cart, online payment, and a full catalog? Do you have experience with online stores, not just with business cards? Have you integrated forms with Telegram, email, or CRM? Can you store UTM tags in applications? Can you connect GA4, Google Tag Manager, Meta Pixel, and TikTok Pixel? Can you create a basic SEO structure? Will the site be fast and work well on mobile? Will it be possible to later connect Google Merchant Center? Will it be possible to later connect CRM, such as KeyCRM or SalesDrive? Will I be able to add products myself after launch? Will you provide a short guide on how to add products and edit pages? Will there be technical support after launch? What examples of similar work can you show? What is the estimated timeline for the first stage? What is the estimated cost of the first stage? What specifically is included in this cost? How do you propose to break the work into stages and payments? Control question: How will you technically make the site now as a landing page + mini-catalog, so that it can later be expanded into a full online store without starting from scratch? For me, it is important not just to be “nice,” but to properly lay the foundation for the future TehnoVek Commerce Platform: site, products, applications, CRM, advertising, delivery, credit/installment, analytics, and further scaling.

It is necessary to implement a full cookie consent management mechanism (Cookie Consent) on the OpenCart (3 pcs) websites and configure Google Consent Mode v2. Requirements: install and configure a CMP (Cookie Management Platform) or another solution for managing user consents; implement a full Cookie Consent banner with options to accept, reject, and configure cookie categories; set up Google Consent Mode v2 through Google Tag Manager; ensure correct transmission of consent statuses to Google Analytics 4, Google Ads, and other marketing services; configure the operation of analytical and advertising tags so that they only trigger according to the user permissions obtained. Currently, the cookie banner is only informational and does not manage consents, nor does it transmit their status to Google services. A complete setup is required in accordance with the current GDPR and Google Consent Mode v2 requirements.

Experienced OpenCart developer needed for project acceptance and further support I am looking for an experienced OpenCart programmer (not a studio) who can professionally accept the online store from the current developer and will further handle its support, development, and SEO optimization. About the project Online store on OpenCart. The project is approximately 99% ready and verified according to the technical specifications. A technical audit needs to be conducted before the final handover of the site. After the handover, long-term cooperation for project development is planned. Main tasks Conduct an audit of the code and project structure. Check the quality of the implemented functionality. Check the installed modules, their compatibility, and correct operation. Assess the security and stability of the site. Check the performance and suggest recommendations for improvement. Check the implemented SEO part and propose a further optimization plan. Ensure that the project is fully ready for independent support without dependence on the previous developer. Check the correctness of the transfer of all accesses: source code; database; FTP; hosting; domain; email; administrative panel; installed modules and their licenses. If necessary, participate in communication with the current developer during the project handover. Provide a list of recommendations and comments before the final acceptance. Further cooperation After the site acceptance, regular work on the project is planned: development of new functionality; SEO optimization; performance improvement; integration with external services; technical support. Candidate requirements A specialist is needed who: has significant experience specifically with OpenCart; has a good understanding of OpenCart architecture and popular modules; has experience in auditing and supporting existing projects; can reasonably assess the quality of completed work; takes agreements seriously and adheres to agreed deadlines; is interested in long-term cooperation. In your response, please indicate experience working with OpenCart; examples of implemented online stores; whether you have conducted technical acceptance or audits of other projects; estimated cost: technical audit; participation in project acceptance; hourly or project support after the handover. Preference will be given to specialists with many years of experience working with OpenCart, who take their work seriously, adhere to agreed deadlines, and are ready to become a technical partner of the project for the long term.

Development of the Architecture for a Unified Fleet Management Platform for WordPress SitesProject Context There is a fleet of several dozen WordPress sites hosted on a single server and maintained by one team. The sites are gradually being transitioned to a unified development and support standard — a common design system with a unified block library (ACF + Gutenberg) and a unified security standard. An architecture is required for centralized management of this fleet.Task A technical architecture for a unified fleet management platform for WordPress sites needs to be developed. The platform is not a metrics dashboard, but a full-fledged system for centralized management and access.Platform Requirements Single Sign-On for Super Administrator — a single entry point for managing all sites in the fleet: overview of status, versions, compliance status. One-click access to the admin panel of each site — the ability to enter the wp-admin of any site in the fleet from a single interface, without storing/entering passwords for each site separately. A well-thought-out authentication mechanism is required (tokens with limited lifespan, binding to a specific user, complete access logging). Role Segmentation: the super admin sees and manages the entire fleet; administrators of individual sites have access only to their own sites. Unified Design System with Site-Level Customization — a common block library (ACF + Gutenberg), distributed to all sites through a central update mechanism, but with the ability for local customization of blocks for a specific site without losing compatibility with future updates of the library. Common Monitoring and Alert Dashboard — status of sites and server, alerts about outages/problems, update status and compliance of each site with respect to the unified standard. Convenient Addition of New Sites to the Network — the platform must support quick cloning/deployment of a new site based on a unified standard (Core plugin, design system) and connect it to the Hub with minimal manual steps.Architectural Constraints (Important) WordPress Multisite is not considered and is not suitable for this task. The reason is not the convenience of the interface, but the fundamental architectural properties of Multisite: A shared database and core for all sites in the network mean a single point of failure: an incorrect plugin or core update can simultaneously disable all sites in the network, not just one. A shared pool of server resources (PHP workers, database connections) means that abnormal load on one site (promotion, traffic spike, attack) degrades the performance of all other sites in the network, including those not related to this load. This systemic property of Multisite cannot be eliminated by process or discipline — therefore, an architecture is required where each site remains an independent installation (own database), and unification and centralized management are achieved by other means.Preliminary Architectural Direction Currently, the most promising architectural approach appears to be Hub & Spoke, where independent WordPress installations (“Spokes”), each with its own database, are united: by a common distributable Core plugin (block library, security baseline, bridge module for connection to the Hub); by a central management application (“Hub”) — site registry, one-click login, monitoring, alerts. However, this architecture is not a predetermined solution. If the executor believes that there is a more suitable architectural approach, they may propose an alternative provided it is technically and economically justified. A separate task within the terms of reference — a reasoned analysis and recommendation: to build the Hub from scratch custom or to take a ready-made self-hosted solution (MainWP, InfiniteWP, ManageWP or analogs) as a basis and expand it under specific requirements (integration with the Core plugin, compliance tracking of block versions, future marketing layer). A comparative assessment of timelines, support costs, flexibility, and limitations of each option is needed, with a clear recommendation.Architectural Requirements When designing the solution, the following non-functional requirements must be considered: fault tolerance and absence of a single point of failure for the fleet of sites; the ability for independent updating, rollback, and maintenance of each site; minimization of blast radius during failures and update errors; the ability for horizontal scaling as the number of sites grows; security of centralized management and delegated access; the possibility of subsequently isolating the Hub into a separate infrastructure without changing architectural principles; expandability of the platform for adding new centralized services. Moreover, the architecture must remain viable when the number of sites increases from several dozen to 100+ without the need for a fundamental revision of the chosen approach.Long-Term Development of the Platform The platform is viewed as a long-term foundation for the company's digital ecosystem, not just as a tool for administering WordPress sites. When designing, the possibility of subsequently adding centralized services (for example, managing marketing activities, analytics, component library, integrations, and other modules) without the need to rework the basic architecture must be considered.Technologies The specific stack is not predetermined — the executor independently proposes and justifies technologies in the architectural document (language/framework for the Hub, hosting/deployment model, authentication mechanism, etc.), based on the requirements of the task. A reasoned proposal for technologies is a mandatory part of the work result, alongside a comparison of custom vs ready-made solutions for the Hub.What is Required from the Executor Experience in designing multi-site/multi-tenant architectures on WordPress (principally — NOT based on Multisite) Practical experience with MainWP/InfiniteWP/ManageWP or similar fleet management systems — understanding their capabilities and limitations at the API/extendability level Experience in developing production-level WordPress plugins (ACF, Gutenberg block development, REST API) Understanding security issues when building centralized/delegated access systems (token-based auth, access auditing, minimizing blast radius) Ability to prepare architectural documentation: diagrams, API contracts between Hub and sites, data schemaWork Format The first stage — an architectural document with a reasoned solution (custom vs ready-made solution), a scheme of component interaction, API contract Hub ↔ Core plugin, phased implementation plan. The document should include a wireframe scheme of the platform interface (key screens: site registry, admin access, monitoring dashboard). Following the approval of the architecture — further cooperation may be possible. Important Note Independent architectural development is expected, based on practical experience in designing and operating similar systems. It is not sufficient to provide a compilation of general recommendations or standard responses generated by AI. Each key architectural decision must be accompanied by a technical justification: why this approach was chosen, what alternatives were considered, what its advantages, limitations, and potential risks are in the context of this project. If necessary, the executor should refer to practical experience, existing solutions, documentation, open-source projects, or other sources that confirm the viability of the proposed architectural solutions.