EC-CUBE إلى Shopify + Next.js: دليل الهجرة للتجارة الإلكترونية اليابانية

إذا كنت تدير متجر EC-CUBE في اليابان وشعرت بألم الحفاظ على نموذج PHP أحادي الكيان موزع محليًا، فأنت لست وحدك. لقد ساعدنا عدة شركات تجارة إلكترونية يابانية في الهجرة من EC-CUBE (الإصدارات 2.x و 3.x و 4.x) إلى واجهات متاجر Shopify بدون رأس مدمجة مع Next.js خلال السنتين الماضيتين. كل واحد منهم قال الشيء ذاته بعد ذلك: "كان يجب أن نفعل هذا عاجلاً."

لكن هنا الحقيقة -- هذه الهجرة معقدة حقًا. EC-CUBE له جذور عميقة في ثقافة التجارة اليابانية. فهو يتعامل مع أشياء مثل حقول Furigana على العناوين، وطرق الدفع اليابانية (مدفوعات الكونبيني، والفوترة الحاملة، والتحويلات البنكية عبر Pay-easy)، وحسابات الشحن بناءً على مناطق Japan Post. لا يمكنك ببساطة تفعيل مفتاح والانتقال إلى Shopify. تحتاج إلى استراتيجية.

هذا الدليل هو مستند الاستراتيجية الذي تمنيت أن أكون قد حصلت عليه عندما قمنا بأول هجرة EC-CUBE لنا في عام 2024.

جدول المحتويات

• لماذا تهاجر بعيدًا عن EC-CUBE في 2026
• فهم معمارية EC-CUBE
• لماذا Shopify Plus + Next.js للتجارة الإلكترونية اليابانية
• تدقيق ما قبل الهجرة والتخطيط
• استراتيجية هجرة البيانات
• التعامل مع طرق الدفع اليابانية
• تعيين الشحن والإنجاز
• بناء واجهة متجر Next.js
• هجرة SEO والحفاظ على عناوين URL
• اعتبارات UX المحددة لليابان
• مقاييس الأداء: EC-CUBE مقابل Shopify بدون رأس
• التوقعات الزمنية والميزانية
• الأسئلة الشائعة

لماذا تهاجر بعيدًا عن EC-CUBE في 2026

كان EC-CUBE بمثابة العمود الفقري للتجارة الإلكترونية اليابانية لما يقرب من عقدين. طورته شركة Lockon Co., Ltd. (الآن EC-CUBE Co., Ltd.)، فقد هيمن على السوق اليابانية عندما كانت الخيارات محدودة. لكن المشهد تغير بشكل كبير.

إليك ما يدفع الشركات بعيدًا:

صيانة الأمان كابوس. وصل EC-CUBE 2.x إلى نهاية عمره منذ سنوات، لكن عددًا مفاجئًا من المتاجر لا تزال تعمل عليه. حتى EC-CUBE 4.x يتطلب تصحيحات ثابتة. في عام 2024 وحده، كان هناك ثلاثة تنبيهات أمان حرجة لـ EC-CUBE 4، بما في ذلك ثغرة حقن SQL (CVE-2024-22345) التي أثرت على آلاف المتاجر. إذا كنت تستضيف ذاتيًا، فهذه مشكلتك لحلها.

تكاليف استضافة PHP مستمرة في الارتفاع. يعني تشغيل EC-CUBE على VPS أو خادم مخصص في اليابان (عادةً على Sakura Internet أو XSERVER أو AWS Tokyo) أنك تدفع مقابل البنية التحتية وشهادات SSL وصيانة قاعدة البيانات ومراقبة الخادم. يقضي متجر EC-CUBE النموذجي متوسط الحجم ¥50,000–¥200,000 شهريًا فقط على الاستضافة والصيانة.

نظام الإضافات آخذ في الانكماش. فقد سوق إضافات EC-CUBE المتطورين. لم يتم تحديث العديد من إضافات الدفع والشحن الشهيرة لـ EC-CUBE 4.2+. إذا اعتمد متجرك على إضافات طرف ثالث، فقد تجد نفسك عالقًا في إصدار قديم بدون مسار ترقية.

أداء الجوال سيئة. تم تصميم معظم موضوعات EC-CUBE في عصر الاستجابة الثقيلة. متوسط درجات Lighthouse للمتاجر EC-CUBE التي قمنا بتدقيقها يتراوح حول 25-40 على الجوال. هذا لن ينجح عندما تؤثر Core Web Vitals مباشرة على تصنيفات Google الخاصة بك في اليابان.

فهم معمارية EC-CUBE

قبل أن تتمكن من الهجرة، تحتاج إلى فهم ما تهاجر منه. تختلف معمارية EC-CUBE بشكل كبير حسب الإصدار:

الميزة	EC-CUBE 2.x	EC-CUBE 3.x	EC-CUBE 4.x
الإطار	PHP مخصص	Silex (Symfony micro)	Symfony 4/5
قاعدة البيانات	PostgreSQL/MySQL	PostgreSQL/MySQL	PostgreSQL/MySQL
محرك القوالب	Smarty	Twig	Twig
معمارية الإضافات	Hooks/overrides	Event-based	Symfony bundles
ORM	مخصص	Doctrine	Doctrine
API	لا شيء (بناءات مخصصة)	REST محدود	REST + GraphQL محدود

مخطط قاعدة البيانات هو حيث تصبح الأمور مثيرة للاهتمام (ومؤلمة). تخزن متاجر EC-CUBE بيانات المنتج، بيانات العميل، وسجل الطلبات في مخطط طبيعي لكن محدد EC-CUBE. جداول dtb_product و dtb_product_class و dtb_customer و dtb_order هي الجداول الأساسية التي ستحتاج إلى استخراجها.

يستخدم EC-CUBE 4.x كيانات Doctrine، مما يجعل استخراج البيانات نظيفًا إلى حد ما. لكن إذا كنت على 2.x، استعد لتصدير SQL الخام مع مشاكل الترميز (بيانات Shift-JIS أو EUC-JP الموروثة لا تزال شائعة).

لماذا Shopify Plus + Next.js للتجارة الإلكترونية اليابانية

أريد أن أكون صريحًا: Shopify ليست الخيار الوحيد. يمكنك الهجرة إلى منصات أخرى مثل commercetools أو Medusa أو حتى منصة يابانية أحدث مثل BASE أو STORES.jp. لكن بالنسبة لعمليات التجارة الإلكترونية اليابانية المتوسطة إلى الكبيرة، فإن Shopify Plus مدمجة مع واجهة أمامية بدون رأس Next.js تحقق نقطة حلوة.

حضور Shopify في اليابان قد نضج. منذ فتح مكتبهم في طوكيو وإطلاق دعم اللغة اليابانية الكامل، عالجت Shopify معظم الفجوات المحددة لليابان. يدعم Shopify Payments الآن بطاقات JCB بشكل أصلي. واجهة المسؤول مترجمة بالكامل. والأهم من ذلك، يدعم Shopify Plus حسابات الضرائب اليابانية بما في ذلك نظام 軽減税率 (معدل الضريبة المنخفض) للأغذية والمشروبات.

يعطيك Next.js ميزة الأداء. واجهة متجر بدون رأس مبنية مع Next.js (باستخدام Storefront API الخاص بـ Shopify أو طبقة البيانات الأساسية الخاصة بـ Hydrogen) تسمح لك بتقديم صفحات ثابتة ومعروضة على الخادم من الحافة. نرى بشكل روتيني درجات Lighthouse للأداء 90+ على الجوال لعمليات البناء Next.js Shopify الخاصة بنا. هذا قفزة ضخمة من درجة 30 النموذجية لـ EC-CUBE.

يتعامل Storefront API مع التعقيد. يدعم Storefront API الخاص بـ Shopify (الإصدار 2025-04 اعتبارًا من كتابة هذا) الحقول الوصفية والمحتوى المترجم والعملات المتعددة والخيارات المخصصة للمنتجات -- كل ما تحتاجه لتكرار مرونة EC-CUBE.

إذا كنت تقيم ما إذا كانت معمارية بدون رأس مبنية على Next.js منطقية لمتجرك المحدد، فالإجابة تقريبًا تعتمد دائمًا على حجم الكتالوج الخاص بك واحتياجات التخصيص. تحت 100 منتج مع متغيرات بسيطة؟ قد يكون موضوع Shopify القياسي جيدًا. تكوينات المنتجات المعقدة أو التخصيص الثقيل أو عدة واجهات متاجر؟ استخدم بدون رأس.

تدقيق ما قبل الهجرة والتخطيط

لا تلمس سطرًا واحدًا من الكود حتى تكمل هذا التدقيق:

1. تعيين تعقيد الكتالوج

وثق كل نوع منتج وهيكل متغير وحقل مخصص في متجر EC-CUBE الخاص بك. يمكن لجدول dtb_product_class الخاص بـ EC-CUBE أن يحتفظ بمزيج متغير معقد لا ينطبق 1:1 على نموذج متغير Shopify (والذي يحتوي على حد أقصى 100 متغير لكل منتج وحد أقصى 3 خيارات).

إذا كان لديك منتجات بها أكثر من 3 أنواع خيارات (على سبيل المثال، الحجم والاللون والمواد والنقش)، فستحتاج إلى استخدام ميزة Combined Listings الخاصة بـ Shopify (التي تم إطلاقها في 2024) أو إعادة هيكلة معمارية المنتجات الخاصة بك باستخدام الحقول الوصفية وخصائص عناصر الأسطر.

2. جرد بيانات العميل

تخزن EC-CUBE بيانات عميل غنية بما في ذلك:

• 姓名 (اسم العائلة / الاسم المحدد، حقول منفصلة)
• フリガナ (Furigana للاسم)
• 郵便番号 (الرمز البريدي مع ملء العنوان التلقائي)
• عناوين شحن متعددة لكل عميل
• أرصدة النقاط (ポイント)
• سجل المشتريات مع تتبع الحالة التفصيلي للطلب

يتعامل نموذج العميل الخاص بـ Shopify مع حقول الأسماء وعناوين متعددة بشكل أصلي. لكن برامج النقاط / الولاء تحتاج إلى حل من طرف ثالث مثل Smile.io أو نظام مبني على الحقول الوصفية المخصص.

3. جرد التكاملات

اسرد كل نظام خارجي يتصل به متجر EC-CUBE الخاص بك:

• بوابات الدفع (GMO Payment Gateway و SB Payment Service و PAY.JP)
• واجهات برمجيات الشحن (Yamato Transport و Sagawa Express و Japan Post)
• برامج المحاسبة (弥生会計 و freee و MoneyForward)
• أنظمة الجرد / ERP
• التسويق عبر البريد الإلكتروني (Mailchimp و SendGrid أو الخدمات اليابانية مثل Benchmark Email)

4. توثيق هيكل عنوان URL

قم بتصدير كل عنوان URL من متجر EC-CUBE الخاص بك. هذا حاسم لهجرة SEO. تبدو أنماط عنوان URL الافتراضية لـ EC-CUBE مثل:

/products/detail/{product_id}
/products/list?category_id={id}
/mypage/
/cart/

ستحتاج إلى خرائط إعادة توجيه لكل هذه.

استراتيجية هجرة البيانات

إليك خط أنابيب الهجرة الذي نستخدمه:

تصدير بيانات المنتج

بالنسبة لـ EC-CUBE 4.x، يمكنك استخدام أدوات Doctrine CLI أو كتابة أمر Symfony لتصدير المنتجات كـ JSON:

// EC-CUBE 4.x product export command
$products = $this->productRepository->findAll();
$exportData = [];

foreach ($products as $product) {
    $variants = [];
    foreach ($product->getProductClasses() as $class) {
        $variants[] = [
            'sku' => $class->getCode(),
            'price' => $class->getPrice02IncTax(),
            'stock' => $class->getStock(),
            'class_category1' => $class->getClassCategory1()?->getName(),
            'class_category2' => $class->getClassCategory2()?->getName(),
        ];
    }
    
    $exportData[] = [
        'id' => $product->getId(),
        'name' => $product->getName(),
        'description' => $product->getDescriptionDetail(),
        'variants' => $variants,
        'images' => array_map(fn($img) => $img->getFileName(), $product->getProductImages()->toArray()),
    ];
}

بالنسبة لـ EC-CUBE 2.x، أنت تبحث عن SQL خام:

SELECT 
    p.product_id,
    p.name,
    p.main_comment,
    pc.product_code,
    pc.price02,
    pc.stock
FROM dtb_product p
JOIN dtb_product_class pc ON p.product_id = pc.product_id
WHERE p.del_flg = 0 AND pc.del_flg = 0;

انتبه لترميز الأحرف. إذا كانت قاعدة البيانات الخاصة بك EC-CUBE 2.x تستخدم EUC-JP، فقم بالتحويل إلى UTF-8 قبل استيراده في أي مكان:

mysqldump --default-character-set=eucjpms your_db | iconv -f EUC-JP -t UTF-8 > export_utf8.sql

الاستيراد إلى Shopify

استخدم Admin API الخاص بـ Shopify (REST أو GraphQL) لإنشاء المنتجات بشكل برمجي. طفرة productCreate في GraphQL هي أفضل صديق لك هنا:

mutation productCreate($input: ProductInput!) {
  productCreate(input: $input) {
    product {
      id
      title
      variants(first: 100) {
        edges {
          node {
            id
            sku
          }
        }
      }
    }
    userErrors {
      field
      message
    }
  }
}

قم بإنشاء سكريبت هجرة في Node.js أو Python يقرأ بيانات EC-CUBE المصدرة ويقوم بإنشاء منتجات Shopify. قم بتضمين تحديد معدل الطلب -- يحتوي Shopify API على حد أقصى 2 طلب / ثانية لـ REST وحد أقصى تكلفة لـ GraphQL.

هجرة العميل

يعمل استيراد العميل عبر API الخاص بـ Shopify بشكل جيد، لكن لاحظ أنه لا يمكنك هجرة كلمات المرور. سيحتاج جميع العملاء إلى إعادة تعيين كلماتهم المرور بعد الهجرة. أرسل بريدًا إلكترونيًا مُعاد التصميم جيدًا (باللغة اليابانية، بالطبع) يشرح الهجرة ويوفر رابط إعادة تعيين كلمة المرور.

بالنسبة لبيانات العميل نفسها، قم بتعيين حقول EC-CUBE إلى Shopify:

حقل EC-CUBE	حقل Shopify	ملاحظات
name01 (姓)	last_name	معكوس للغة اليابانية
name02 (名)	first_name	معكوس للغة اليابانية
kana01 (セイ)	metafield	لا توجد حقول Furigana أصلية
kana02 (メイ)	metafield	لا توجد حقول Furigana أصلية
email	email	التعيين المباشر
point	metafield or loyalty app	يحتاج إلى معالجة مخصصة
addr01 (都道府県)	province	تعيين إلى أكواد المقاطعات الخاصة بـ Shopify
addr02 (市区町村)	city + address1	قد تحتاج إلى التسلسل

سجل الطلبات

هجرة الطلبات التاريخية اختيارية ولكن موصى بها للاستمرارية في خدمة العملاء. استخدم Order API الخاص بـ Shopify لإنشاء طلبات مع "financial_status": "paid" و "fulfillment_status": "fulfilled" للطلبات المكتملة.

التعامل مع طرق الدفع اليابانية

هنا حيث تصبح الأمور معقدة. يتوقع المستهلكون اليابانيون خيارات دفع محددة ليست قياسية في التجارة الإلكترونية الغربية.

يدعم Shopify Payments الآن بطاقات ائتمان بما في ذلك JCB و Visa و Mastercard و American Express في اليابان. رسوم المعالجة 3.25%–3.4% + ¥0 لكل معاملة لـ Shopify Plus.

لطرق الدفع الأخرى:

طريقة الدفع	الحل على Shopify	ملاحظات
コンビニ決済 (محل الراحة)	KOMOJU أو GMO Payment Gateway app	ضروري لحوالي 15% من الطلبات الإلكترونية اليابانية
代引き (الدفع عند الاستلام)	Shopify native COD	مدمج، يعمل بشكل جيد
銀行振込 (تحويل بنكي)	طريقة دفع يدوية	Shopify يدعم هذا بشكل أصلي
キャリア決済 (فوترة الناقل)	KOMOJU	docomo و au و SoftBank
PayPay	PayPay for Shopify app	الدفع بـ QR الأكثر شيوعًا في اليابان
Amazon Pay	Amazon Pay app	اعتماد عالي في اليابان
後払い (اشتر الآن ادفع لاحقًا)	Paidy و atone	شائع جدًا في اليابان

تستحق KOMOJU ذكرًا خاصًا. أصبحت بوابة الدفع الفعلية للمتاجر على Shopify في اليابان، وتدعم مدفوعات Konbini والتحويلات البنكية وفوترة الناقل والمزيد من خلال تكامل واحد. تكاملهم مع Shopify Plus قوي ولم تواجه مشاكل كبيرة معه.

تعيين الشحن والإنجاز

عادةً ما يستخدم EC-CUBE الإضافات لـ Yamato Transport (ヤマト運輸) و Sagawa Express (佐川急便) و Japan Post (日本郵便). تتعامل هذه الإضافات مع إنشاء تسميات الشحن وتكامل رقم التتبع واختيار فتحة وقت التسليم (配達時間指定).

على Shopify، لديك عدة خيارات:

• Ship&co -- تطبيق شحن مبني باليابان يتكامل مع جميع ناقلي الشحن اليابانيين الرئيسيين. يتعامل مع طباعة التسميات بالشكل الصحيح.
• Shopify Shipping -- دعم ناقل Japan محدود اعتبارًا من 2025، لكنه يتحسن.
• Custom Carrier Service API -- قم ببناء حاسبة معدل شحن خاصة بك إذا كان لديك تسعير معقد قائم على المناطق.

اختيار فتحة وقت التسليم (午前中 و 12-14時 و 14-16時 وما إلى ذلك) أمر حاسم للعملاء اليابانيين. يتطلب هذا إما امتداد خروج مخصص على Shopify Plus أو تطبيق خارجي مثل 配送日時指定 .amp.

بناء واجهة متجر Next.js

بالنسبة للواجهة الأمامية، نستخدم Next.js 15 مع App Router و Server Components. إليك المكدس المعتاد لنا:

Next.js 15 (App Router)
├── Shopify Storefront API (GraphQL)
├── next-intl (للدعم الإقليمي اليابانية)
├── Tailwind CSS 4
├── Framer Motion (animations)
└── Vercel (deployment, Tokyo region edge)

هناك بعض الأشياء التي تعلمناها عند بناء واجهات متاجر يابانية مع Next.js:

تحسين الخط

الخطوط اليابانية على الويب ثقيلة. وزن Noto Sans JP العادي وحده يبلغ حوالي 1.8MB. استخدم next/font مع subsets وفكر في الخطوط المتغيرة:

import { Noto_Sans_JP } from 'next/font/google';

const notoSansJP = Noto_Sans_JP({
  subsets: ['latin'],
  weight: ['400', '500', '700'],
  display: 'swap',
  preload: true,
});

حتى أفضل، استخدم font-display: optional للنصوص غير الحرجة وقدم مكدس خط النظام كبديل: "Hiragino Kaku Gothic ProN", "Hiragino Sans", Meiryo, sans-serif.

مكونات الخادم لصفحات المنتج

جلب بيانات المنتج في Server Components للقضاء على حالات التحميل من جانب العميل:

// app/products/[handle]/page.tsx
export default async function ProductPage({ params }: { params: { handle: string } }) {
  const product = await shopifyFetch({
    query: PRODUCT_QUERY,
    variables: { handle: params.handle },
  });

  return (
    <div>
      <ProductGallery images={product.images} />
      <ProductDetails product={product} />
      <AddToCartButton variantId={product.variants[0].id} />
    </div>
  );
}

نقوم ببناء جميع واجهات متاجر Shopify بدون رأس باستخدام هذا النمط، والفرق في الأداء مقابل موضوع Liquid التقليدي أو حتى Hydrogen ملحوظ.

هجرة SEO والحفاظ على عناوين URL

هذا هو الجزء الذي يبقيني مستيقظًا ليلاً في مشاريع الهجرة. غالبًا ما يكون لمتاجر التجارة الإلكترونية اليابانية سنوات من رأس مال SEO المتراكم، وقد تؤدي الهجرة غير الصحيحة إلى خفض حركة البحث العضوية لعدة أشهر.

استراتيجية الإعادة التوجيه

قم بإنشاء خريطة إعادة توجيه كاملة. كل. عنوان URL واحد. استخدم عمليات إعادة التوجيه next.config.js للأنماط الثابتة:

// next.config.js
module.exports = {
  async redirects() {
    return [
      {
        source: '/products/detail/:id',
        destination: '/products/:handle',
        permanent: true,
      },
      {
        source: '/products/list',
        destination: '/collections/:collection',
        permanent: true,
      },
    ];
  },
};

لعمليات إعادة التوجيه الديناميكية (تعيين معرفات منتجات EC-CUBE إلى مقابض Shopify)، استخدم البرامج الوسيطة أو جدول بحث إعادة التوجيه المخزن في قاعدة البيانات أو KV store.

البيانات المنظمة

نادراً ما تحتوي متاجر EC-CUBE على بيانات منظمة صحيحة. استفد من هذه الفرصة لتطبيق مخطط Product و BreadcrumbList و Organization و FAQPage. تتميز SERPs اليابانية في Google بنتائج غنية.

تفاصيل SEO اليابانية

• احتفظ بعلامات العنوان الخاصة بك أقل من 30 حرفًا باللغة اليابانية (وليس 60 مثل الإنجليزية)
• وصف التعريف: 80-120 حرف ياباني
• تأكد من وجود علامات hreflang الصحيحة إذا كانت لديك صفحات متعددة اللغات
• أرسل خريطة الموقع إلى بحث Google Console و Bing Webmaster Tools (لـ Bing حصة سوق ذات مغزى في اليابان)

اعتبارات UX المحددة لليابان

لـ UX التجارة الإلكترونية اليابانية اختلافات ثقافية غالبًا ما يتجاهلها المطورون الغربيون:

• كثافة المعلومات -- يتوقع المستهلكون اليابانيون مزيدًا من معلومات المنتج المرئية على الصفحة. لا تقلل الأشياء بشكل مفرط.
• إشارات الثقة -- اعرض سياسات الشحن وسياسات العودة ومعلومات الشركة بشكل بارز. يبحث المتسوقون اليابانيون بدقة.
• ملء الرمز البريدي التلقائي -- طبق 郵便番号 → ملء العنوان التلقائي باستخدام Japan Post API أو مكتبة مثل zipaddress.js.
• اللغة الشرفية -- استخدم Keigo المناسب (敬語) في نسخة UI. يمكن أن تبدو اللغة غير الرسمية غير محترمة.
• تكامل رسائل LINE -- لـ LINE 96 مليون مستخدم نشط شهريًا في اليابان. دمج LINE Login و LINE notifications.

مقاييس الأداء: EC-CUBE مقابل Shopify بدون رأس

إليك بيانات حقيقية من هجرة أكملناها في Q1 2025 لبائع أزياء ياباني (~3,000 SKU):

المقياس	EC-CUBE 4.2 (قبل)	Next.js + Shopify (بعد)	التحسن
Lighthouse Performance (Mobile)	34	92	+170%
LCP	4.8s	1.2s	-75%
FID/INP	380ms	45ms	-88%
CLS	0.24	0.02	-92%
Time to First Byte	1.8s	0.18s	-90%
Page Weight (product page)	3.2MB	680KB	-79%
معدل التحويل	1.8%	2.9%	+61%
التكلفة الشهرية للاستضافة	¥180,000	¥45,000	-75%

تحسن معدل التحويل وحده دفع مقابل الهجرة بأكملها خلال ثلاثة أشهر. لا ترى كل مشروع أرقامًا بهذا الحد من الدراماتيكية، لكن تحسينات الأداء بهذا الحجم بشكل متسق تحرك الإبرة.

التوقعات الزمنية والميزانية

دعونا نكون واقعيين حول ما تستغرقه هذه الهجرة:

حجم المتجر	المنتجات	الجدول الزمني	نطاق الميزانية (¥)
صغير	<500	8-12 أسبوع	¥3,000,000-5,000,000
متوسط	500-5,000	12-20 أسبوع	¥5,000,000-12,000,000
كبير	5,000+	20-32 أسبوع	¥12,000,000-25,000,000+

تتضمن هذه النطاقات التصميم والتطوير ونقل البيانات ضمان الجودة ودعم الإطلاق. تفترض أنك تعمل مع فريق متمرس. إذا لم يقم فريقك بهجرة التجارة الإلكترونية اليابانية من قبل، أضف 30-50% لكل من الجدول الزمني والميزانية لمنحنيات التعلم.

عادةً ما تبدو التكاليف الجارية الشهرية بعد الهجرة مثل:

• Shopify Plus: 2,300 دولار / شهر (~¥345,000)
• Vercel Pro: 20 دولار / شهر لكل عضو في الفريق
• KOMOJU: رسوم المعاملات فقط
• Ship&co: ¥2,000/month base
• الإجمالي: ~¥380,000-450,000/month مقابل ¥400,000-800,000/month للتجارة الإلكترونية المستضافة ذاتيًا مع قدرات مكافئة

لنظرة شفافة على كيفية تقسيم تسعير المشروع، راجع صفحة التسعير الخاصة بنا.

الأسئلة الشائعة

هل يمكنني الهجرة من EC-CUBE 2.x مباشرة إلى Shopify + Next.js؟ نعم، لكن هجرات EC-CUBE 2.x أكثر تعقيدًا بسبب مخطط قاعدة البيانات الأقدم والمشاكل المحتملة لترميز Shift-JIS/EUC-JP والافتقار إلى ORM حديث. ميزانية وقت إضافي لتنظيف البيانات وتحويلها. نوصي بالتصدير إلى تنسيق محايد (CSV أو JSON في UTF-8) أولاً، ثم بناء سكريبتات الاستيراد لـ Shopify.

هل سأفقد تصنيفات Google الخاصة بي عند الهجرة من EC-CUBE؟ لا إذا تعاملت مع عمليات إعادة التوجيه بشكل صحيح. طبق عمليات إعادة توجيه 301 لكل عنوان URL، احتفظ بخريطة الموقع XML الخاصة بك، وحافظ على علامات العنوان وأوصاف التعريف الخاصة بك متسقة. توقع تقلبًا مؤقتًا (2-4 أسابيع) حيث يعيد Google الزحف، لكن التصنيفات يجب أن تتعافى وتتحسن عادةً بسبب درجات Core Web Vitals الأفضل.

هل يدعم Shopify حساب الضرائب اليابانية بما في ذلك معدلات الضرائب المنخفضة؟ نعم. يدعم Shopify نظام ضريبة الاستهلاك الياباني بما في ذلك معدل 軽減税率 (8% منخفض للأغذية والمشروبات مقابل معدل 10% قياسي). يمكنك تكوين معدلات الضرائب لكل مجموعة منتجات وتتولى Shopify الحساب بما في ذلك متطلبات الإيصالات المؤهلة للفاتورة (インボイス制度).

كيف أتعامل مع نظام نقاط EC-CUBE بعد الهجرة إلى Shopify؟ لا يحتوي Shopify على نظام نقاط أصلي مكافئ لوظيفة ポイント المدمجة في EC-CUBE. أفضل خيارات لك هي Smile.io (يدعم اليابانية) أو LoyaltyLion أو حل مخصص باستخدام حقول Shopify الوصفية ودالة بدون خادم. بالنسبة لأرصدة النقاط الموجودة، قم بهجرتها كحقول وصفية على سجلات العميل وقم ببناء تدفق استرجاع في عملية الدفع الخاصة بـ Next.js.

هل Hydrogen أفضل من Next.js لواجهة متجر Shopify بدون رأس؟ يعتمد ذلك. Hydrogen (إطار Shopify المبني على Remix) متكامل بشكل وثيق مع Shopify ويعطيك بعض البدائل التجارية المدمجة اللطيفة. لكن Next.js له نظام بيئي أكبر بكثير وموارد مجتمع أفضل ودعم Edge Runtime أفضل على Vercel ومرونة أكثر إذا كنت تريد مبادلة الواجهات الخلفية للتجارة. بالنسبة للتجارة الإلكترونية اليابانية على وجه التحديد، تعطيك إمكانيات البرامج الوسيطة Next.js و توجيه i18n ميزة على Hydrogen. لقد بنينا مع كليهما ونفضل Next.js لمعظم المشاريع -- انظر إمكانيات تطوير Next.js الخاصة بنا.

هل يمكنني تشغيل EC-CUBE ومتجر Shopify الجديد بالتوازي أثناء الهجرة؟ بالتأكيد، وننصح به. قم بتشغيل كلا النظامين في نفس الوقت لمدة 2-4 أسابيع. استخدم DNS أو وكيل عكسي لتحويل حركة المرور تدريجيًا. يتيح لك هذا التحقق من صحة أن الطلبات تتدفق بشكل صحيح وتتم معالجة المدفوعات بشكل صحيح والمخزون يبقى متزامنًا قبل قطع الاتصال بالكامل.

ماذا عن ميزة رسالة البريد الإلكتروني الإخبارية الخاصة بـ EC-CUBE (メールマガジン)؟ يحتوي EC-CUBE على نظام النشرة الإخبارية عبر البريد الإلكتروني المدمج الذي تعتمد عليه العديد من المتاجر. قم بهجرة قائمة المشتركين إلى منصة تسويق بريد إلكتروني متخصصة مثل Klaviyo (التي تحتوي على تكامل ممتاز مع Shopify)، أو إذا كنت بحاجة إلى دعم اللغة اليابانية والقوالب، فراجع Benchmark Email أو SendGrid. الهجرة مباشرة -- قم بتصدير عناوين البريد الإلكتروني وتواريخ الموافقة من جدول dtb_customer الخاص بـ EC-CUBE واستيردها في المنصة الجديدة.

كم من الوقت تستغرق هجرة البيانات الفعلية؟ يعد تنفيذ سكريبت الهجرة نفسه سريعًا عادةً -- بضع ساعات لمعظم المتاجر. الجزء الذي يستغرق وقتًا طويلاً هو بناء واختبار سكريبتات الهجرة والتحقق من تكامل البيانات والتعامل مع الحالات الحدودية (منتجات بدون صور وعملاء بعناوين بريد إلكترونية غير صحيحة وطلبات ذات حالات مخصصة). بالنسبة للمتجر الذي يحتوي على 3,000 منتج و 50,000 عميل، توقع 2-3 أسابيع من وقت تطوير الهجرة والاختبار.