Upgrade Custom Core PHP 8.3 B2B Platform to Dynamic Multi-Domain (Single Codebase)

@rajat07me

I’ve worked on custom PHP platforms and understand this is a refactoring job, not a rebuild. The key here is to make both domains run from one codebase while keeping your current logic, root scripts, and infrastructure intact. I can handle the domain-based config loading, table mapping, language file extraction, and RTL/LTR conversion using proper CSS logical properties. If you want, I can also outline the file structure changes clearly before starting.

@ykarora26

With vast experience in PHP architecture, I understand the need to consolidate your B2B platform into a Single Codebase serving multiple domains. My expertise in dynamic routing and database mapping aligns perfectly with your requirements. Could you share more details on the current language handling setup to ensure a seamless transition during the unification process? Regards, Yogesh Kumar

@vashishtrupinder

I understand you need to unify your two domains into one PHP 8.3 codebase, with dynamic routing and table mapping, without touching existing logic. I've done similar refactoring before and can handle this cleanly. I'll keep the core files untouched, and the 5-day deadline works for me. Your plan to run database updates yourself is fine. Unlimited revisions until you're completely satisfied. Let me know if you'd like to start with a small piece of the demo work to see how we work together. I'm available to start immediately and would be happy to discuss your requirements in detail. Best Regards, Azad

@Herculesz

Hi, this is a classic legacy-platform refactor where the value is in centralizing domain behavior without destabilizing a working B2B system, and I’ve handled that kind of constrained production change before. The real engineering risk is not routing itself; it’s introducing domain-aware config and table resolution in a way that doesn’t create hidden regressions across shared queries, includes, and root-level automation scripts. The closest match on my side is Custom Feature Development & Integration, where I stepped into an existing codebase, reviewed the current structure, and made targeted changes across UI, database, and core behavior without forcing a rebuild. HubSpot CRM Implementation & Interactive Senior Living Website is also relevant because it involved PHP-backed production flows that had to remain stable while extending behavior. I usually structure this as a thin domain-resolution layer, a centralized config map for language/table aliases, and a clean separation between presentation localization and data-source switching. That keeps core files intact while reducing the chance of scattered conditional logic. For the RTL/LTR requirement, I’d keep the shift at the layout token level using logical properties rather than page-specific overrides, so the interface stays maintainable. These are the kinds of changes I design for long-term production use, not just to make two domains render correctly for a week. Thanks, Hercules

@naminghn

Hi there, I understand you're looking to refactor your existing B2B platform architecture into a dynamic multi-domain setup. I can implement the necessary dynamic routing to serve content based on incoming domains, along with the required database table mapping for different languages. I'll ensure that the original core functionality remains intact and that your deadline is met without compromising any existing infrastructure. Your satisfaction is my priority, and I guarantee I will deliver a high-quality result. Regards, Ali

@AnumFatima210

Hi, I'm interested in your project "Upgrade Custom Core PHP 8.3 B2B Platform to Dynamic Multi-Domain (Single Codebase)". I have relevant experience and can deliver quality results within your timeline and budget. I'd love to discuss the details. Please feel free to reach out.

@denisSolution

Hi, It looks like the main challenge is keeping the two domains aligned without duplicating logic or breaking what’s already working. The key parts will be the domain detection, table mapping, and clean RTL switching without hardcoding. I’ve done similar multi-domain refactors where the main concern was making sure the core didn’t need changes while still serving different configurations. The localization and CSS switching parts are straightforward once the routing and database mapping are in place, but the hard part is ensuring background scripts and automation files keep running as they are. The way I’d set this up is to add a lightweight router that reads the domain on each request and sets the language, table prefix, and RTL direction from config files. The existing PHP logic stays untouched because the mapping happens at the database layer, not inside functions. For RTL, CSS logical properties will handle the layout shift automatically—no manual overrides needed. Nothing about this should take more than a few days if the existing structure isn’t too tangled. The only real unknown is whether the parallel tables are strictly identical; if they’re not, some fields might need renaming to match before the mapping works. Thanks, Denis

@Anilsingh1992

Hi, thank you for posting your project! I have 7+ years of experience with Core PHP, PHP 8.x, MySQL, multilingual systems, and large existing codebases. I can refactor your platform into a clean single-codebase architecture with domain-based routing, dynamic database mapping, AR/EN language files, and automatic RTL/LTR using CSS logical properties. I’ll preserve your existing business logic, scripts, automation, and infrastructure without unnecessary changes. I can complete the structural refactoring within your 5-day deadline and provide clear implementation instructions for the database updates.

@vishal1145

Your parallel table architecture will create maintenance hell the moment you add a third market or need to sync data across domains. Right now, every schema change requires double the work, and your codebase has no abstraction layer to handle multi-tenancy cleanly. Quick questions - are you planning to add more regional domains beyond these two? And do business_profile and business_profile_arabyos share identical schemas, or are there structural differences that forced the split? Here is the architectural approach: - DYNAMIC ROUTING: Build a domain detection middleware that sets locale context at bootstrap, routing all requests through a single entry point without duplicating controllers. - DATABASE ABSTRACTION: Replace hardcoded table names with a config-driven mapper that appends locale suffixes dynamically, allowing queries like $db->table('business_profile') to resolve correctly per domain. - I18N EXTRACTION: Migrate all hardcoded strings into keyed language arrays loaded at runtime, ensuring zero inline text remains in templates while preserving existing HTML structure. I've refactored similar legacy PHP platforms for 4 B2B clients who needed multi-region support without rewriting their entire stack. Let's schedule a 20-minute technical call to review your current bootstrap flow and table dependencies before we lock the implementation plan.

@toriquldev123

Hello There! I’m Md Toriqul Islam, an experienced PHP developer specializing in custom Core PHP applications, multi-domain architecture, localization, database-driven platforms, and safe legacy-code refactoring. I understand you need EgyptMart and Arab-Mart unified into one Core PHP 8.3 codebase with domain-based routing, dynamic database table mapping, AR/EN language files, and automatic RTL/LTR CSS using logical properties—without disrupting existing core logic or background scripts. I am skilled in PHP 8.3, MySQL, dynamic routing, i18n, database abstraction, CSS Logical Properties, RTL/LTR layouts, and legacy-system refactoring. I can preserve existing files and functionality while implementing the structural changes within your 5-day deadline. Looking forward to hearing from you. Best regards, Md Toriqul Islam

@BarryCrouch

Hello, Dynamic table mapping for parallel language tables risks breaking existing queries if any use hardcoded table names in JOINs or raw SQL — refactoring must audit every database call, not just config. Five days is tight for safe i18n extraction; missing one hardcoded string breaks RTL layout consistency. The approach wraps all DB access in a domain-aware resolver that swaps table suffixes transparently, while CSS logical properties replace directional rules globally. Language files get generated via static analysis to catch embedded strings before manual review. Background scripts remain untouched by isolating routing logic to HTTP entry points only. Do any background automation scripts reference language-specific tables directly? This determines whether dynamic mapping applies universally or needs script-level exceptions. Share your current config structure and one sample page with mixed hardcoded/localized content so I can assess extraction complexity within the deadline.

@Eliteinno

hello, The parallel table setup is where this refactor gets interesting, because business_profile and business_profile_arabyos will almost certainly have drifted apart over time. One will have a column the other lacks, or slightly different types. So the first job is a schema diff between every pair, since dynamic table mapping only works cleanly when both sides answer the same queries. The mapping itself belongs in one bootstrap file that reads the host, sets the domain context, and returns table names through a single resolver function. Every query then asks that resolver instead of naming a table. That way nothing in your root scripts needs to change, they keep hitting their current tables, and the automation stays alive exactly as it is. For the layout, logical properties handle direction with one stylesheet, so RTL and LTR come from a dir attribute on the html tag rather than a second CSS file to maintain. Two questions! Are the two table sets identical in structure right now, or already different? Do the background scripts run per domain, or against one database only? have a nice day

@Olywebart

The bottleneck is unifying two domain-specific database schemas and routing within a single PHP 8.3 codebase. The root cause is parallel table structures for different languages coupled with static domain detection logic. I will implement dynamic domain detection to route requests and dynamically map database table names in the config based on the domain. UI strings will be externalized into language files with CSS Logical Properties for RTL/LTR auto-shifting to avoid manual page flipping. Core backend logic remains untouched and I will validate behavior with domain-specific tests before deployment How do you currently handle configuration and environment variables between the two domains in your PHP platform?.

@fullstack0407

As a seasoned full-stack developer with a specialization in core PHP, I have successfully executed numerous projects of similar complexity and magnitude. My extensive experience working with complex web applications positions me to meticulously handle the requirements of your B2B platform upgrade to a multi-domain framework. With expertise in automated n8n processes, dynamic database mapping, and localization through I18n, I can bring the required structural refactoring to your platform whilst perfectly preserving your current infrastructure. Moreover, my sound understanding of CSS enables me to implement modern layouts, incorporating RTL/LTR shifting using CSS Logical Properties, thus eliminating any manual hardcoded "page flipping." I am also adept at extracting UI strings from pages into dedicated language files to ensure streamlined localization across languages like Arabic and English. Reliability and adherence to deadlines are my top priorities. Therefore, you can rest assured that your project will be delivered within a maximum of 5 consecutive calendar days as agreed. Additionally, my track record of maintaining functional logic and automation files during such architectural refactoring assures you that none of your existing functional flows will be disrupted along the way. Trust me to impeccably execute this project without altering the existing technical infrastructure. Partner with me for a streamlined multi-domain solution for your B2B platforms.

@rosscarter1011

Cron scripts running from the CLI will crash if your domain router assumes the server host variable is always present. A central bootstrap router can inspect the incoming host header for web requests and accept an environment argument for CLI jobs, mapping table name constants dynamically across both domains without modifying your raw SQL queries. I will extract UI strings into clean associative arrays, configure CSS logical properties so directional layouts shift automatically via the HTML dir attribute, and ensure your background scripts remain untouched. You will receive clear SQL instructions for any database adjustments and a single unified codebase ready for testing on staging. How are your background cron scripts currently triggered, and do they query both Arabic and English tables in the same run? thanks.

@sf264

Hello, I would be excited to unify the architecture into a single codebase that will dynamically serve two given domains. Let's chat and discuss more details. I am looking forward to working with you, Fahad.

@longngoc2307

Hi - Truong here "ONE CORE PHP CODEBASE FOR TWO DOMAINS" — you need domain, language, database, and RTL/LTR behavior separated cleanly without breaking existing automation. I’d resolve the active domain once into a configuration layer, map the correct tables and language files from there, and use CSS logical properties for RTL/LTR instead of duplicated page layouts. I’d preserve the existing root scripts and core behavior, with changes kept structural and reversible. Can you provide the current config/routing files and confirm both domains already point to the same application root? Looking forward to working with you.

@abdf2010

Hi, I read your project "Upgrade Custom Core PHP 8.3 B2B Platform to Dynamic Multi-Domain (Single Codebase)" and I can help. I have solid experience in PHP, CSS, Software Architecture and can deliver clean, reliable work. Happy to discuss scope and start right away.

@dinobartolome

The hardest part of this isn't the domain detection or the language files. It's the dynamic table mapping. You've got parallel tables like business_profile and business_profile_arabyos, and you need a config layer that resolves the right table name based on which domain hit the server. I've done exactly this pattern in custom PHP, where a single config array maps domain to table suffixes and the query layer picks it up automatically. No ORM needed, just a clean resolver function that wraps your existing queries. For the routing piece, a small bootstrap file that reads the server host and sets the active domain config before anything else loads. Language files are straightforward string extraction. The CSS logical properties for RTL/LTR is actually the cleanest part since modern browsers handle margin-inline-start and padding-inline-end natively. I've worked with PHP 8.3 and MySQL on B2B platforms where preserving existing automation scripts was non-negotiable. 10+ years doing this. Your 5-day timeline works. I'd structure it as: day 1-2 domain detection plus table mapping config, day 3 i18n extraction, day 4 CSS logical properties pass, day 5 testing across both domains. Want to walk through the table mapping config structure? I can sketch it out before we start so you see exactly how it fits your codebase.