Де я можу розмістити файли .php, .js, .html, .css із сторонніх файлів, які взаємодіють із розширенням, яке я розробляю?


10

Скажімо, я хочу розробити розширення Magento, яке інтерфейсує, скажімо, з пакетом графіків з відкритим кодом або галереєю зображень або будь-яким іншим, що НЕ є частиною самого розширення. Коли ви завантажуєте (окремо від розширення), сторонній LB постачається у власному синглі .zip з усіма його .php, .js, .html та .css разом.

Чи розміщую я бідного власника сайту, який бажає встановити моє розширення разом із стороннім лінтом, тягарем розірвати оригінальну сторону .zip один від одного та змусити їх поставити .js в / js, .php в / lib, css в / шкіра тощо?

Або є загальновизнаний "демпінг-майданчик" для будь-якого стороннього .zips, де можна зручно розпакувати завантаження як це є і зробити з ним?

Відповіді:


6

Я не знаю, чи є одна правильна відповідь на це питання, оскільки це насправді залежить від коду, який ви включаєте.

Якщо ви хочете включити сторонню бібліотеку php, наприклад sdk для зовнішнього API, її слід помістити в каталог / lib вашого проекту Magento, щоб він міг бути включений вашим розширенням, яке споживає його.

Однак ви також використовуєте js та css як приклади. Якщо ви використовуєте js від третіх сторін у своєму розширенні для виведення коду, наприклад, деякі js, які надають канву діаграми, то це більше ніж ймовірно, має бути поміщено в каталог / js, щоб воно могло бути включене вашим розширенням. Що стосується css, його, мабуть, слід додати до основної / типової теми та шкіри.

На жаль, система розширень Magento 1 не спрощує розповсюдження подібних речей, оскільки файли розповсюджуються через весь проект, а не самостійно, що містяться в одному dir. З цим дещо допомагають такі інструменти, як Magento Composer Installer та Modman .


4

При завантаженні (окремо від розширення) сторонні розширення надходять у свій єдиний .zip з усіма його .php, .js, .html та .css разом.

Я завжди був прихильником розбиття конвенцій від самого джерела, хоча це може бути неоднозначно з Magento 1.

За умови, що ліцензія сторонніх бібліотек дає змогу поєднати її, слід розпакувати її та перепакувати разом із розширенням, оскільки немає власного механізму розпакування окремої підтеки (я можу помилятися).

Куди ці активи йдуть, залежить від типу та внутрішньої організації файлів. Чисті бібліотеки JS повинні підходити до цього ./js/. Файли, виконані на стороні сервера, належать під ./lib/, зазначаючи, що будь-який клас PHP під ./lib/може бути завантажений автоматично за принципом автоматичного завантаження (по суті PSR-0) (див. Умову про автоматичне завантаження Zend Framework 1). Нічого в розділі ./lib/не можна (слід) отримувати через клієнт (посилання ./lib/.htaccess).


Дякую Бен. Ваша відповідь має сенс, але це означає, що власники сайтів не можуть легко модернізувати сторонні версії до останньої версії, незалежно від розширення Magento, яке інтерфейсує до неї. Якщо не зрозуміти, як все це звисає, і навіть тоді болісно розмістити всі шматочки в потрібних прорізах. Це благо, в тому сенсі, що версії розширення та lib сторонніх розробників залишаються послідовними, але біль, коли нові версії сторонній lib пропонують виправлення помилок та нові функції, продовжуючи підтримувати зворотну сумісність.
фрі

1
"Це благо, у тому сенсі, що версії розширення та сторонній ліб залишаються послідовними ..." Ось такий квиток! Їх зміни - це ваші зміни. Це все трохи простіше в Magento 2 завдяки композитору.
орієнтири

1

Отже, ви хочете створити розширення, і для його побудови використовуєте зовнішній ресурс / пакет. На мою думку, який би пакунок ви не використовували у своєму розширенні, ваше розширення має відповідати кращим практикам Magento. Це означає, що ви повинні відокремити всі js, css, образи від зовнішнього ресурсу і розмістити їх у base\defaultкаталогах пакунків для тем.

тобто не існує такого унікального місця для розміщення сторонніх пакетних ресурсів. Зрештою, коли ви доставляєте круте розширення, всі js, css та зображення, пов’язані з вашим розширенням, слід зберігати там, де інший розробник зазвичай збирається шукати, і це майже у всіх випадках - це base/defaultтематичний пакет.

Коротко

Усі ваші розширення js повинні підпадати під

skin\frontent\base\default\js\[your_extension]\[all_of_your_js_files]
skin\frontent\base\default\css\[your_extension]\[all_of_your_css_files]
skin\frontent\base\default\images\[your_extension]\[all_of_your_images]

//for third parties, you can create an inner directory, to specify it
skin\frontent\base\default\js\[your_extension]\[your_external_resource]\[resource_js_files]
skin\frontent\base\default\css\[your_extension]\[your_external_resource]\[resource_css_files]
skin\frontent\base\default\images\[your_extension]\[your_external_resource]\[resource_image_files]

Таким чином, інший розробник може легко знайти js, css та зображення (також із ваших зовнішніх ресурсів) вашого розширення. Оскільки ви використовуєте додатковий підкаталог для вказівки зовнішніх файлів ресурсів всередині каталогу імен розширень, це дасть іншим кращий підказник, що ваше розширення покладається на деякі сторонні пакети.

Тому я рекомендую вам відокремити зовнішні пакунки та зробити їх частиною вашого розширення, щоб інший розробник міг легко знайти ваші залежності. :-)

РЕДАКЦІЯ - 1

Ви не повинні створювати ваші додаткові тягарі для власника вашого сайту. Ви можете уникнути цієї складності, якщо правильно вирівняти розширення. Це означає, що якщо ви зберігаєте всі пов’язані файли у вказаних місцях каталогів, тоді все, що повинен робити власник сайту, - схопіть розширення, а потім Об’єднайте розширення з кореневим каталогом програми. тобто вирівняйте розширення належним чином. Це повинно виглядати так.

/app
|_____code\community\Namespace\Module\...
|_____design
|        |_____frontend\base\defalt\...
|        |_____adminhtml\base\defalt\...

/skin
|_____frontend\base\default\js|css|images\[your_extension]\all_theme_related_files
|_____frontend\base\default\js|css|images\[your_extension]\all_theme_related_files

РЕДАКТ - 2

Якщо є деякі пакети, які мають бути спільними для всіх програм Magento (наприклад, бібліотеки javascript або пакету php тощо), то ви можете помістити їх у \libкаталог.

Це правда, що може існувати повторюваний файл, якщо два розширення покладаються на однакові пакети ресурсів. Вони також можуть використовувати різні версії одного пакета ресурсів. Але в основному ваше розширення має використовувати лише ресурс вашого розширення (і може покладатися на ресурси Magento за замовчуванням), і воно не повинно покладатися на інші ресурси розширення, якщо тільки ваше розширення не є "розширюваною версією" стороннього розширення.


Дякую. Ваша відповідь скоріше сприймає розробницьку точку зору, а не сторону власника сайту. Але я здогадуюсь, що це так у Магенто? Я знаю інших CMS, які домовились про розпакування архівів / файлів сторонніх організацій, зберігаючи всі файли разом так, як є в оригіналі.
фрі

1
Так. Я знаю, що розчаровувати ресурс пакета неприємно. Магенто вимагає цього. Простий спосіб для цього не існує. Найкращі практики Magento кажуть: "Вам слід тримати все js, css, imagesв base\defaultпакеті". Також дивіться мій код редагування
Rajeev K Tomy

Привіт Раєєв ... Наступним наслідком розміщення файлів зовнішнього ресурсу / lib під "your_extension" є те, що він не може бути спільним для інших розширень, які також можуть використовувати ресурс / lib. Таким чином, ви отримуєте кілька копій, можливо, різних версій CLASHING, завантажених на одній сторінці. Ой!
фрі

дивіться мої зміни, будь ласка
Rajeev K Tomy

0

У Magento є власний менеджер пакунків під назвою Magento Connect. Ви повинні перевірити цей посібник з офіційної документації, щоб повністю зрозуміти, як повинен виглядати пакунок. Ви можете запакувати свій модуль із установки Magento, як тільки зрозумієте структуру.


Дякую за вашу відповідь, але це не зовсім те, що я просив. Справа не в тому, як упакувати моє розширення, це про те, куди у дерево файлів Magento слід розмістити сторонні файли, які НЕ є частиною ядра чи мого розширення, але їх потрібно включити як частину системи. Де я можу користувачам помістити ці файли? Чи є стандартне місце (або плями) для файлів сторонніх виробників?
фрі

Це насправді пов'язане з посиланням, яке я вам надіслав. Js і css мають власні папки для пакетів, як і будь-який інший файл розширення. Файли Php можуть знаходитися під папкою кореневої lib або всередині папки модуля всередині папки lib.
mbalparda

Добре, дякую. Отже, ваша відповідь така: Так, розробники сайтів Magento повинні розпакувати сторонній архів, витягнути частини PHP, JS, HTML та CSS з цього архіву та повторно поширити ці файли у відповідних слотах у дереві файлів Magento. НЕ вважається найкращою практикою дозволяти розробнику сайтів просто розпаковувати весь архів третьої сторони в деякому загально узгодженому каталозі, призначеному для цієї мети, звідки пов'язане розширення (и) буде включати файли сторонніх організацій за потребою.
фрі

Так. Все, що ви описали, вже охоплене в процесі упаковки, описаному в документації.
mbalparda

Добре я прочитав цю документацію, але вона нічого не говорить про моє запитання. Він говорить лише про файли, які є частиною розширення, яке ви розробляєте та хочете упакувати. Тут не сказано, куди слід розміщувати сторонні файли, які НЕ є частиною розширення, як-от календар, галерея зображень або пакет графіків. Можливо, ви не хочете пакувати їх разом із розширенням, яке ви розробляєте, щоб їх можна було оновити самостійно. Тоді виникає питання, куди слід поставити сторонні файли? Який найкращий підхід для них?
фрі

0

В основному Magento використовує власну структуру для зберігання .php, .phtml, js, css, imagesфайли.

Для розробника розширень magento дуже важливо дотримуватися шляху magento. Перевірте це посилання .

Тому,

  1. Ваші .phpфайли мають перейти під app/code/communityпапку
  2. Ваші jsфайли можуть перейти в jsпапку або в skin/frontend or adminhtml/your_theme_pack/your_theme/jsпапку
  3. Ваші cssфайли можуть перейти до skin/frontend or adminhtml/your_theme_pack/your_theme/cssпапки
  4. Ваші imagesфайли можуть перейти до skin/frontend or adminhtml/your_theme_pack/your_theme/imagesпапки
  5. Ваша files should go toпапка 'html app / design / frontend або adminhtml / template`

PS frontend означає, якщо ваше розширення призначене для переднього зберігання, а adminthml означає, якщо ваше розширення призначене для адміністративної області.

Існує специфічний спосіб зберігати ці файли в магенто, тому слід слідкувати за ними.

Я також перевірив, чи потрібні функції копіювання вже доступні в системі magento / zend. Наприклад, створюючи pdf, надсилати електронну пошту, читати xml тощо, вже вбудовано в magento.

Сподіваюсь, це допомагає.

Оновлення 1

Якщо ви хочете просто затримати свої файли десь, то ви можете їх у будь-якому місці. Ви навіть можете створити нову папку в корені magento. Але це не найкраща практика для магенто, який завантажить ваш сервер під час виконання цих файлів. Ви хочете перевірити це https://magentotherightway.com/


Дякуємо за посилання та пояснення. Але я не розпитую про саме розширення. Я запитую про те, куди поставити код сторонніх розробників, не включений у розширення. Чи є для нього загальноприйняте єдине місце розташування?
фрі

Якщо ви хочете просто затримати свої файли десь, то ви можете їх у будь-якому місці. Ви навіть можете створити нову папку в корені magento. Але це не найкраща практика для магенто, який завантажить ваш сервер під час виконання цих файлів. Ви хочете перевірити цю magentotherightway.com
Адарш Хатрі

Розподілені розширення ніколи не повинні встановлюватися в localкодовий пул.
орієнтири
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.