Вывод товаров в магазине Opencart в виде прайс-листа

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.

I'm looking for an experienced programmer to work on a website that runs on ModX Revolution. Currently, a number of technical improvements need to be made, including: making changes to the website; replacing photos, banners, and size grids; updating contact information; other minor edits; connecting Google Analytics; integrating the payment system LiqPay, etc. In the future, I plan to regularly develop the website, so I'm looking for a responsible specialist for long-term cooperation who can promptly carry out the necessary improvements. Requirements: confident experience with ModX Revolution; quality execution of tasks; adherence to agreed deadlines; willingness for ongoing collaboration Work on the website - https://marimoth.com Write to me and we will negotiate Maria

Hello everyone. I am looking for a specialist who can help solve the problem with the React source files. The issue is that they are missing. Therefore, a new repository needs to be created, extract as much as possible from DevTools/source maps, and then restore the project. I will provide details to the candidates. I look forward to your responses.

The site is built on the Next.js framework (based on React). All points in the technical specification need to be completed. The technical specification is attached in the file. I look forward to your proposals.

there is a website https://perfect-okna.com.ua/ main problems: SPEED ANALYSIS (Performance) Key issues (typical for such websites): · Large unoptimized images (JPEG/PNG without compression, no WebP). · Lack of lazy loading for images in the catalog. · Non-minified CSS/JS, many unnecessary libraries connected. · No caching at the browser level, CDN not used. · Server does not provide compression (gzip/brotli). · HTTP/2 not used. Checklist "Speed": · Compress all images, convert to WebP and add fallback. · Set up lazy loading for images (loading="lazy"). · Minify HTML, CSS, JS. Combine files where appropriate. · Enable Gzip/Brotli on the server. · Set cache headers (Cache-Control, Expires) for static content. · Connect CDN (Cloudflare for free). · Remove unnecessary plugins/scripts (especially if WordPress). · Use asynchronous loading for non-critical scripts (async/defer). On the homepage, there is often no clear structure "who we are - what we offer - why choose us - how to order". · The window constructor (if available) can be confusing, without hints, the final price is not visible immediately. · On mobile devices, the menu may shift, the calculator is not adapted for fingers. · Feedback forms are long, without phone masking, without validation. · No "quick actions": call with one click, messengers, chat. · Lack of "breadcrumbs" on internal pages. · Create a mobile version without horizontal scrolling, buttons no less than 48x48 px. · On the homepage, add a price calculator "in 3 clicks" immediately. · In the header – clickable phone number (tel:), messengers (Viber/Telegram) with icons. · Forms: only name + phone + "comment" field (optional). Phone mask. · Add a floating button "Quick Order / Calculate Cost" on mobile. · On product cards – "Buy in 1 click" button (opens a mini-form). · Add "breadcrumbs", improve navigation through sections. · Check text contrast, font size (at least 14 px on mobile). · No urgent offer (time-limited promotions). · Insufficient social proof (reviews, video reviews, number of completed works). · It is not explained that the price is "turnkey" (installation, delivery, dismantling). · No CTA (call to action) on every screen. Add a "counter" – how many clients have already chosen, how many windows installed. · Video reviews from real clients (short, 30–60 sec). · Block "Calculate in 30 seconds" right on the first screen. · Show the "turnkey" price: window + installation + delivery, with a transparent breakdown. · Promotions with a timer: "15% discount for orders by the end of the week". · Popup window with an offer for a free measurement when the user tries to close the tab. What to do: · Interactive 3D window configurator (color change, opening, glazing) – more on this later. · Mini-game or test: "Which window is suitable for your apartment?" · Cases: photos "before/after" in real interiors. · Guides: "How to choose windows for a noisy street", "Energy saving: which glazing to choose". · Heating savings calculator after window replacement. Urgent (Critical) 1. Mobile adaptation of the entire site, especially the constructor and cart. 2. Speed up loading: image compression, caching, CDN. 3. Quick order button (One Click Buy) on all product cards. Popup chat with the ability to leave a message in Viber/Telegram. 5. Valid HTTPS and redirect from HTTP → HTTPS for all pages. 6. Microdata Schema.org (Organization, Product, BreadcrumbList, Review). Important (High) 1. Update the homepage: add USP, promotions, videos, quick calculator. 2. "Promotions" page with a timer, updated monthly. 3. Callback form – simple, with a mask and automatic city code substitution. 4. CRM integration (e.g., amoCRM / Bitrix24) for automatic lead capture. 5. Add online payment (LiqPay, WayForPay) at least for prepayment for measurement. 6. SEO URL structure: /produkciya/plastikovi-vikna/, not /?page_id=123. Desired (Medium) 1. Expand the blog with articles for key queries (5 articles at once). 2. Interactive constructor with 3D view (separate block below). 3. Product filter by characteristics (size, profile, color, price). 4. Personal client cabinet, where you can see the order status. 5. Generation of PDF commercial proposal directly on the site. HOW TO IMPROVE THE CONFIGURATOR (Window Configurator) If it is currently a regular form with dropdown lists – this is outdated. A modern 3D configurator is needed: Mandatory features: · Step-by-step wizard: 1) room selection, 2) dimensions, 3) number of sashes, 4) color, 5) glazing, 6) fittings, 7) mosquito net. · Instant price recalculation at each step (AJAX). · 3D visualization (Three.js or ready js framework). · Saving the selected configuration in PDF (server-side generation) and sending to email. · Button "Send calculation to manager" – and a card with all parameters flies to CRM. · Ability to share a link to your configuration (for example, to send to husband/wife). · Full adaptation for touch gestures (swipe to rotate the 3D model on the phone) Price is negotiable!