تحليل جذري قبل التنفيذ · moonui4 · فرع hazemdev4 · 2026-07-20 · كل رقم هنا مقيس على البيئة الحيّة، مش مستنتج
شاشتا /app/core/products و/app/core/product-catalog مابتعرضش ولا صورة واحدة، رغم إن 1018 من 1024 منتج عندهم صورة مخزّنة فعلًا. وبالتوازي، رفع صورة من شاشة المنتجات بيرجّع HTTP 422.
المطلوب من المالك حرفيًا: «الصور تبقى من مكان واحد — سواء رفع من المنتجات أو رفع من الاستور، يترفع في نفس المكان بنفس الآلية»، مع ملاحظة إضافية: «ممكن نعتمد أكتر على الاستور علشان في موبايل أبليكيشن أصلًا خلصان».
| المسار | الآلية | مكان التخزين | قابل للعرض؟ | مين بيستخدمه |
|---|---|---|---|---|
| أ — مسار المنتج | HandlesImageUpload |
uploads/productsقرص public |
أيوه — رابط مباشر | كل الباك-إند |
| ب — المرفقات | AttachmentController |
attachments/{company}/{YYYY-MM}قرص private |
لأ — تنزيل مصادَق فقط | واجهة الأدمن وحدها |
١٦ متحكّم في الباك-إند بيستخدموا المسار (أ)، من ضمنهم المتحكّمان اللي يهمّانا:
Core/app/Http/Controllers/ProductController.php ← شاشة المنتجات
WebStore/app/Http/Controllers/Admin/AdminProductController.php ← إدارة المتجرHandlesImageUpload باسمين، وده كان بيبان ازدواج. لكن بتاع WebStore ٨ أسطر بيعيد تصدير بتاع الجذر حرفيًا:
trait HandlesImageUpload {
use \App\Http\Controllers\Concerns\HandlesImageUpload;
}| القياس | القيمة | الدلالة |
|---|---|---|
products بصورة | 1018 / 1024 | المسار (أ) مليان |
product_images | 11 صف | المعرض شبه فاضي |
attachments | 0 | المسار اللي الواجهة بتقرأ منه فاضي تمامًا |
GET /api/core/products | بترجّع image + image_url | الـAPI سليمة |
| صورة تجريبية / مستوردة | 200 image/png · 200 image/jpeg | الملفات موجودة وتُخدَم |
يعني البيانات صح، والـAPI صح، والملفات صح — الواجهة ببساطة مابتبصّش على image_url إطلاقًا، بتنزّل blob من نظام المرفقات الفاضي.
في WP-IMG-1 ضفت تحقّقًا يرفض رفع صورة كمرفق على منتج، لمنع تكرار الغلط الأصلي. لكن معرض صور المنتج في شاشة الأدمن بيرفع بالطريقة دي بالظبط (attachmentAccept شامل image/*). أعدت الاختبار على الحيّ:
POST /api/core/attachments (png على منتج) → HTTP 422
"Product images cannot be uploaded as attachments …"api/store — السطح الصحيح — فالصور هتظهر عنده فور ظهورها في المتجر، بدون شغل إضافي.| الطبقة | الحالة | الشغل المطلوب |
|---|---|---|
| التخزين (قرص + مجلد) | موحّد | لا شيء |
المخطط (products.image + product_images.position) | موحّد | لا شيء — ولا هجرة |
| الباك-إند (١٦ متحكّم) | موحّد على trait واحد | لا شيء |
| واجهة المتجر | تقرأ المسار الصحيح | لا شيء — منتهية ومتحقَّقة |
| واجهة الأدمن — العرض | جزئيًا | الكتالوج اتصلّح · شاشة المنتجات باقية |
| واجهة الأدمن — الرفع | مكسور 422 | التحويل لنقاط نهاية المنتج |
The unification the owner asked for already holds at the storage, schema, backend and storefront layers. The entire remaining gap is the admin frontend: one screen's display, and the upload path.
src/app/features/products/products.component.ts ← العرض + الرفع (الأساسي)
src/app/features/products/products.component.html ← معاينة الشبكة والمعرض
src/app/core/services/product.service.ts ← أُضيف فيه توصيل نقاط المنتج ✅
src/app/core/models/product.model.ts ← أُضيف image_url ✅
src/app/features/product-catalog/product-catalog.* ← ✅ منتهي (44f1d9bb)
لا تُلمس:
Modules/Core/app/Http/Requests/StoreAttachmentRequest.php ← الحارس يبقى
Modules/Core/app/Http/Controllers/AttachmentController.php ← المستندات تفضل
projects/storefront/** ← منتهٍPUT مع ملفات: Laravel مابيقراش multipart/form-data في PUT حقيقي. لازم POST + _method=PUT، وإلا الملفات تصل فاضية بصمت.images[] بيستبدل المعرض كله بالترتيب. إرسال صورة واحدة جديدة يمسح الباقي — سلوك تدميري لو الواجهة فهمته إضافة.product_images منفرد — نوقف ونبلّغ، لا نخترع ولا نحذف من جهة العميل.basename() — وإلا صورة شركة تظهر على منتج شركة تانية.| WP | النطاق | الحالة |
|---|---|---|
| IMG-3أ | عرض الكتالوج من image_url + نموذج + خدمة | ✅ 44f1d9bb |
| IMG-3ب | شاشة المنتجات: العرض ثم الرفع عبر نقاط المنتج · تضييق attachmentAccept | جزئي — محفوظ في stash@{0} |
| IMG-3ج | إثبات دائري: رفع من الأدمن → يظهر في الأدمن و في المتجر | لم يبدأ |
| IMG-4 | مشروط بقرار الموبايل — توحيد سطح الـAPI | محجوب |
api/storeأكّد المالك إن التطبيق بيستخدم سرفيس الاستور. يعني الموبايل على السطح اللي بيقرأ products.image / product_images الصحيح — مفيش شغل إضافي، والصور هتظهر عنده فور ظهورها في المتجر. ده يلغي WP IMG-4 المحجوب ويحصر الباقي في شاشة أدمن واحدة.
مابعرفش عنه أي حاجة، ومفيش أي أثر ليه في الباك-إند. بحثت في المسارات والإعدادات وسجل التغييرات — صفر إشارة. والإجابة بتغيّر حجم الشغل جذريًا:
| لو التطبيق يستهلك… | الأثر |
|---|---|
api/store 207 مسار | مفيش شغل إضافي — المتجر بيقرأ المسار الصحيح أصلًا، والموبايل هيشوف الصور فورًا. |
api/core 154 مسار | لازم نتأكد إنه يقرأ image_url مش المرفقات — وإلا هيقع في نفس الحفرة. |
| سطح خاص به | مسار تالت غير معروف — لازم جرد قبل أي توحيد. |
محتاج منك: التطبيق بيضرب على أنهي عنوان؟
attachments فاضي هنا، لكن التركيبات الأخرى مليانة. نبني ترحيلًا لمرة واحدة، ولا نكتفي بالتوحيد للأمام؟ ترشيحي: ترحيل مؤجَّل لتذكرة مستقلة — مش شرط لإصلاح moonui4.api/store، ده إعادة معمارية مش إصلاح صور، وتستاهل تحليلها لوحدها.https://moonui4.elbaset.com/app/core/products · /app/core/product-cataloghttps://moonui4.elbaset.com/store/npx ng build --base-href /app/ — العلم إجباري لتطبيق الأدمن (المتجر بقى مثبَّتًا).hazemdev4. لا نشر لعميل.api/store — أكّده المالك 2026-07-20.