Gdzie umieścić pliki .php, .js, .html, .css z biblioteki innej firmy, która współpracuje z opracowanym przeze mnie rozszerzeniem?


10

Powiedzmy, że chcę opracować rozszerzenie Magento, które łączy się, powiedzmy, z pakietem wykresów Open Source lub galerią obrazów lub czymkolwiek innym, co NIE jest częścią samego rozszerzenia. Po pobraniu (oddzielnie od rozszerzenia) biblioteka innej firmy jest dostarczana jako pojedynczy plik .zip ze wszystkimi plikami .php, .js, .html i .css.

Czy umieszczam na biednym właścicielu strony, który chce zainstalować moje rozszerzenie razem z biblioteką innej firmy, ciężar rozdzielenia oryginalnego pliku .zip innej firmy i umieszczenia ich w plikach .js w / js, .php w / lib,. css w / skin itp?

Czy też istnieje ogólnie akceptowany „zrzut” dla zewnętrznych plików zip, w których można wygodnie rozpakować plik w stanie, w jakim się znajduje, i zrobić to?

Odpowiedzi:


6

Nie wiem, czy istnieje jedna poprawna odpowiedź na to pytanie, ponieważ tak naprawdę zależy to od kodu, który podajesz.

Jeśli chcesz dołączyć zewnętrzną bibliotekę php, np. Sdk dla zewnętrznego API, to powinna ona zostać umieszczona w katalogu / lib twojego projektu Magento, aby mogła być dołączona przez twoje rozszerzenie, które ją wykorzystuje.

Jednak używasz również js i css jako przykładów. Jeśli używasz js od stron trzecich w swoim rozszerzeniu do kodu wyjściowego, np. Niektóre js, które renderuje wykres kanwy, powinno to być bardziej niż prawdopodobnie umieszczone w katalogu / js, aby można je było dołączyć do twojego rozszerzenia. W przypadku css prawdopodobnie powinien zostać dodany do podstawowego / domyślnego motywu i katalogów skór.

Niestety system rozszerzenia Magento 1 nie ułatwia dystrybucji tego rodzaju rzeczy, ponieważ pliki są rozproszone w całym projekcie, a nie zawarte w jednym katalogu. Narzędzia takie jak Magento Composer Installer i Modman nieco w tym pomagają.


4

Po pobraniu (oddzielnie od rozszerzenia) rozszerzenia innych firm są dostarczane w jednym pliku .zip ze wszystkimi plikami .php, .js, .html i .css.

Zawsze byłem fanem wróżenia konwencji od samego źródła, chociaż może być to niejednoznaczne w Magento 1.

Pod warunkiem, że licencja na bibliotekę innej firmy zezwala na tworzenie pakietów, należy ją rozpakować i ponownie spakować wraz z rozszerzeniem, ponieważ nie ma natywnego mechanizmu rozpakowywania oddzielnej podbiblioteki (mogę się mylić).

Lokalizacja tych zasobów zależy od typu i wewnętrznej organizacji plików. Biblioteki Pure JS powinny ulec zmniejszeniu ./js/. Pliki, które są wykonywane po stronie serwera, należą do ./lib/, zwracając uwagę, że dowolna klasa PHP ./lib/może być automatycznie ładowana przez (zasadniczo PSR-0) schemat automatycznego ładowania (zob. Konwencja automatycznego ładowania Zend Framework 1). Za ./lib/pośrednictwem klienta (ref. ./lib/.htaccess) Nie można uzyskać dostępu do niczego poniżej .


Dzięki Ben. Twoja odpowiedź ma sens, ale oznacza to, że właściciele witryn nie mogą łatwo zaktualizować biblioteki innej firmy do najnowszej wersji, niezależnie od rozszerzenia Magento, które jest z nią powiązane. Chyba że dokładnie zrozumiesz, jak to wszystko wisi razem, a nawet wtedy bólem jest umieszczenie wszystkich bitów we właściwych miejscach. Jest to błogosławieństwo w tym sensie, że wersje rozszerzenia i biblioteki innych firm pozostają spójne, ale stanowi ból, gdy nowe wersje biblioteki innych firm oferują poprawki błędów i nowe funkcje, jednocześnie zachowując zgodność wsteczną.
fris

1
„To błogosławieństwo w tym sensie, że wersje rozszerzenia i biblioteki innych firm pozostają spójne ...” To jest bilet! Ich zmiany są twoimi zmianami. Wszystko to jest nieco łatwiejsze w Magento 2 dzięki Composer.
zyskuje

1

Więc chcesz utworzyć rozszerzenie i do jego budowy używasz zewnętrznego zasobu / pakietu. Moim zdaniem, niezależnie od tego, jakiego pakietu użyłeś w swoim rozszerzeniu, twoje rozszerzenie powinno być zgodne z najlepszymi praktykami Magento. Oznacza to, że należy oddzielić wszystkie pliki js, css, obrazy od zewnętrznego zasobu i umieścić w base\defaultkatalogach pakietów motywów.

tzn. nie ma takiej unikalnej lokalizacji do umieszczania zasobów pakietu stron trzecich. Ostatecznie, gdy dostarczysz fajne rozszerzenie, wszystkie pliki js, css i obrazy związane z tym rozszerzeniem powinny być przechowywane w miejscu, w którym zwykle będzie szukał inny programista, a prawie w każdym przypadku jest to base/defaultpakiet motywów.

W skrócie

Wszystkie twoje rozszerzenia js powinny się znaleźć

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]

W ten sposób inny programista może bardzo łatwo znaleźć pliki js, css i obrazy (również zasobów zewnętrznych) rozszerzenia. Ponieważ używasz dodatkowego podkatalogu do wskazania zewnętrznych plików zasobów w katalogu nazwy rozszerzenia, da to innym najlepszą wskazówkę, że twoje rozszerzenie polega na niektórych pakietach stron trzecich.

Dlatego polecam oddzielić zewnętrzne pakiety i uczynić je częścią twojego rozszerzenia, aby inny programista mógł łatwo znaleźć twoje zależności. :-)

EDYCJA - 1

Nie należy obciążać rozszerzenia swoim właścicielem witryny. Możesz uniknąć tej trudności, odpowiednio wyrównując rozszerzenie. Oznacza to, że jeśli zapiszesz wszystkie powiązane pliki w określonych lokalizacjach katalogu, to wszystko, co powinien zrobić właściciel witryny, to pobierz rozszerzenie, a następnie Scal swoje rozszerzenie z katalogu głównego aplikacji. tj. wyrównaj prawidłowo swoje rozszerzenie. To powinno wyglądać tak.

/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

EDYCJA - 2

Jeśli istnieją jakieś pakiety, które powinny być współużytkowane przez wszystkie aplikacje Magento (takie jak biblioteka javascript lub pakiet php itp.), Możesz umieścić je w \libkatalogu.

Prawdą jest, że może istnieć duplikat pliku, jeśli dwa rozszerzenia korzystają z tych samych pakietów zasobów. Mogą także używać innej wersji tego samego pakietu zasobów. Ale w zasadzie twoje rozszerzenie powinno wykorzystywać tylko zasoby twojego rozszerzenia (i może polegać na domyślnych zasobach Magento) i nie powinno polegać na zasobach innych rozszerzeń, chyba że twoje rozszerzenie jest „rozszerzoną wersją” rozszerzenia strony trzeciej.


Dziękuję Ci. Twoja odpowiedź faworyzuje punkt widzenia programisty, a nie właściciela strony. Ale chyba tak to wygląda w Magento? Znam inne CMS-y, które uzgodniły miejsca do rozpakowania archiwów / lib stron trzecich, utrzymując wszystkie pliki razem tak, jak są w oryginale.
fris

1
Tak. Wiem, że wydzielanie zasobów pakietu jest frustrujące. Magento tego wymaga. Nie ma na to łatwego sposobu. Najlepsze praktyki Magento mówią „Powinieneś trzymać wszystko js, css, imagesw base\defaultpaczce”. Zobacz także mój kod edycji
Rajeev K Tomy

Cześć Rajeev ... Kolejną konsekwencją umieszczenia zewnętrznych plików zasobów / lib pod „twoim_wydatkiem” jest to, że nie można ich udostępniać innym rozszerzeniom, które również mogą korzystać z zasobów / lib. W rezultacie powstaje wiele kopii, być może różnych wersji KLASY, załadowanych na tej samej stronie. Auć!
fris

proszę zobaczyć moje zmiany
Rajeev K Tomy

0

Magento ma własny menedżer pakietów o nazwie Magento Connect. Powinieneś sprawdzić ten przewodnik z oficjalnej dokumentacji, aby w pełni zrozumieć, jak powinna wyglądać paczka. Po zrozumieniu struktury możesz spakować moduł z instalacji Magento.


Dziękuję za odpowiedź, ale nie do końca o to prosiłem. Nie chodzi o to, jak spakować moje rozszerzenie, chodzi o to, gdzie w drzewie plików Magento umieścić pliki innych firm, które NIE są częścią rdzenia lub mojego rozszerzenia, ale muszą być włączone jako część systemu. Gdzie mam powiedzieć użytkownikom, aby umieścili te pliki? Czy istnieje standardowe miejsce (lub miejsca) dla plików innych firm?
fris

W rzeczywistości jest to związane z linkiem, który ci wysłałem. Js i css mają swoje własne foldery dla pakietów, tak jak każdy inny plik rozszerzenia. Pliki php mogą znajdować się w głównym folderze lib lub w folderze modułu w folderze lib.
mbalparda

Ok dziękuję. Twoja odpowiedź brzmi: tak. Twórcy stron Magento muszą rozpakować archiwum innej firmy, wyciągnąć części PHP, JS, HTML i CSS z tego archiwum i ponownie rozpowszechnić te pliki w odpowiednich miejscach w drzewie plików Magento. NIE jest uważane za najlepszą praktykę zezwalanie konstruktorowi witryny na rozpakowanie całego archiwum strony trzeciej w jakimś wspólnie uzgodnionym katalogu przeznaczonym do tego celu, skąd skojarzone rozszerzenie (rozszerzenia) będzie zawierało pliki stron trzecich w razie potrzeby.
fris

Tak. Wszystko, co opisałeś, jest już objęte procesem pakowania opisanym w dokumentacji.
mbalparda

Cóż, przeczytałem tę dokumentację, ale nie mówi nic o moim pytaniu. Mówi tylko o plikach, które są częścią rozszerzenia, które tworzysz i które chcesz spakować. Nie mówi, gdzie umieścić pliki innych firm, które NIE są częścią rozszerzenia, takie jak kalendarz, galeria zdjęć lub pakiet wykresów. Możesz nie chcieć spakować ich z opracowywanym rozszerzeniem, aby można je było niezależnie aktualizować. Powstaje zatem pytanie, gdzie umieścić pliki stron trzecich? Jakie jest dla nich podejście oparte na najlepszych praktykach?
fris

0

Zasadniczo Magento używa jej własnej struktury do ładowni .php, .phtml, js, css, imagespliki.

Dla deweloperów rozszerzeń magento bardzo ważne jest, aby postępować zgodnie z magento. Sprawdź ten link .

Więc,

  1. Twoje .phppliki powinny przejść do app/code/communityfolderu
  2. Twoje jspliki mogą iść do jsfolderu lub do skin/frontend or adminhtml/your_theme_pack/your_theme/jsfolderu
  3. Twoje csspliki mogą przejść do skin/frontend or adminhtml/your_theme_pack/your_theme/cssfolderu
  4. Twoje imagespliki mogą przejść do skin/frontend or adminhtml/your_theme_pack/your_theme/imagesfolderu
  5. Twój files should go tofolder „html app / design / frontend or adminhtml / template`

Interfejs PS oznacza, że ​​twoje rozszerzenie jest dla sklepu frontowego, a adminthml oznacza, czy twoje rozszerzenie jest dla obszaru administracyjnego.

Istnieją specjalne sposoby przechowywania tych plików w Magento, więc powinieneś ich przestrzegać.

Sprawdziłbym również, czy pożądane funkcje kopiowania są już dostępne w środowisku magento / zend. Na przykład tworzenie pdf, wysyłanie wiadomości e-mail, czytanie xml itp. Są już wbudowane w Magento.

Mam nadzieję że to pomoże.

Aktualizacja 1

Jeśli chcesz po prostu gdzieś przechowywać swoje pliki, możesz je przechowywać w dowolnym miejscu. Możesz nawet utworzyć nowy folder w katalogu głównym Magento. Ale nie jest to najlepsza praktyka dla Magento, które załaduje twój serwer podczas wykonywania tych plików. Chcesz to sprawdzić https://magentotherightway.com/


Dzięki za link i wyjaśnienie. Ale nie pytam o samo rozszerzenie. Pytam o to, gdzie umieścić kod innej firmy nieuwzględniony w rozszerzeniu. Czy istnieje dla niej wspólnie POJEDYNCZA lokalizacja?
fris

Jeśli chcesz po prostu gdzieś przechowywać swoje pliki, możesz je przechowywać w dowolnym miejscu. Możesz nawet utworzyć nowy folder w katalogu głównym Magento. Ale nie jest to najlepsza praktyka dla Magento, które załaduje twój serwer podczas wykonywania tych plików. Chcesz sprawdzić to magentotherightway.com
Adarsh ​​Khatri

Rozszerzenia rozproszone nigdy nie powinny być instalowane w localpuli kodów.
zyskuje
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.