Korzystanie z rozszerzeń debugowania / trybu programisty wystarczającą ochronę

18

Istnieje kilka ciekawych rozszerzeń dla programistów Magento, których zwykle nie chcesz mieć w systemie na żywo.

Jak możesz przechowywać je w repozytorium projektów, ale uniknąć ich ujawnienia w sklepie na żywo?

development debug developer-mode

— Alex
źródło

20

Istnieją dwie stosunkowo nowe techniki, aby to zrobić:

Użyj modmana , abyś sam mógł kontrolować, co wdrożyć dla każdego środowiska. Oznacza to, że działasz modman deploy [name-of-dev-extension]tylko w środowisku deweloperskim.
Użyj magento-kompozytora z różnymi composer.jsonscenariuszami dla różnych środowisk. Jeszcze łatwiejszym sposobem jest określenie tych rozszerzeń jako modułów --require-devdeweloperskich, a następnie zainstalowanie projektu za pomocą przełącznika na komputerze programistycznym.

— użytkownik487772
źródło

1

+ jeden za odniesienie do modmana :) fajna opcja

— Toon Van Dooren

Czy możesz opisać więcej, jak wyglądałoby to wdrożenie specyficzne dla środowiska? Mam na myśli, gdzie mam przechowywać listę modułów, które wdrażam? Zwykle mam folder ze wszystkimi modułami - i znowu muszę oddzielić live i programowanie.

— Alex

@Alex: proszę zobaczyć moją edycję.

— user487772,

@Tim: dzięki! Zredagowałem również twoją odpowiedź teraz.

— Alex

@Alex: Dzięki. Nie wiedziałem tego :-)

— user487772

10

Zazwyczaj można je wygodnie wyłączyć za pomocą flagi konfiguracji, więc są technicznie aktywne, ale nic nie robią. Jeśli ustawisz tę flagę na false w app/etc/local.xmlswoim systemie na żywo, wszystko powinno być w porządku.

— Fabian Schmengler
źródło

To dobre rozwiązanie, chyba że chcesz zachować swój local.xmlplik w repozytorium. Co może być przypadkiem.

— user487772,

Świetna odpowiedź - local.xmlzwykle nie ma jej w repozytorium

— Alex

6

Zobacz MageTrashApp, który powstał niedawno na Magento Hackathon w Berlinie. Umożliwia dezaktywację modułów za pomocą panelu administracyjnego.

— Karen Baker
źródło

5

Prostym sposobem na to jest wyłączenie modułu w / etc / modules, wypchnięcie go, zignorowanie pliku lokalnie i włączenie go ponownie.

— Toon Van Dooren
źródło

W takim przypadku będziesz ograniczony do dokonywania modyfikacji pliku bootstrap rozszerzenia (na przykład modyfikowanie zależności). Również jeśli sprawdzisz, powiedzmy na innym komputerze, będziesz musiał ponownie wykonać wszystkie te sztuczki. Może być jeszcze bardziej niewygodny w zespole kilku programistów.

— user487772,

Jeśli zignorujesz plik lokalnie, jedyne co muszą zrobić inni deweloperzy, to włącz go ponownie. To zajmuje tylko kilka sekund imho.

— Toon Van Dooren,

Dobrze. Ale potem znowu muszą to zignorować lokalnie. Dotyczy to każdego rozszerzenia dla każdej kopii roboczej. Mam na myśli, że twoje rozwiązanie na pewno zadziała, ale jest nieco niewygodne.

— user487772,

prawda, chyba tylko spojrzałem na to z mojej pozycji, zwykle integruję tylko 1 lub 2 narzędzia programistyczne :-)

— Toon Van Dooren

3

Myślę, że najlepszym sposobem na poradzenie sobie z tym jest pozostawienie wszystkich modułów w lokalnym codePool i wyłączenie wszystkich modułów lokalnych na żywo z tą linią w pliku local.xml:

    <disable_local_modules>true</disable_local_modules>

Możesz też wykonać polecenie „Wyłącz wyjście modułu” w backendu swojego środowiska na żywo. (System -> Konfiguracja -> Zaawansowane). Nie wyłącza to jednak całkowicie modułu. Ale może wystarczy, że chcesz się przed tym ukryć.

Jedyną rzeczą, o której myślę, jest napisanie kodu, który to umożliwi. Wystarczy sprawdzić, czy jest w trybie programisty ( Mage::getIsDeveloperMode()), a następnie wyłączyć moduły. Znalazłem więcej szczegółów na temat osiągnięcia tego tutaj: /programming/6520634/magento-how-to-disable-module-programmatically

— Rick Kuipers
źródło

Wszystkie 3 rozwiązania nie są wystarczająco dobre. Wyłączenie localmodułów zmusi cię do przeniesienia wszystkich innych modułów z localcodePool do, communitya także do wszystkich przyszłych rozszerzeń. Wyłączanie modułów wyjściowych, tak jak powiedziałeś, nadal pozwala na rozszerzenie spowalniające twój sklep. A trzecie rozwiązanie będzie wymagało modyfikacji, które zostaną zastąpione aktualizacją rozszerzenia (rozszerzeń).

— user487772,

2

@Tim Zgadzam się, absolutnie. Powinien istnieć lepszy sposób radzenia sobie z tym, powinna istnieć podstawowa konfiguracja blokowania / włączania modułów w trybie programowania.

— Rick Kuipers

3

Zwykle po prostu umieszczam je w moim środowisku testowym, ale nie sprawdzam ich w systemie kontroli wersji, na przykład za pomocą .gitignorepliku, aby wykluczyć ich z rozważania o popełnienie.

— mpaepper
źródło

OP kładł nacisk na utrzymanie rozszerzeń w repozytorium.

— user487772,

1

Na konferencji Imagine 2011 znajduje się slajd Erika Hansena. Podał kod na slajdzie, który jest jak poniżej (dla trybu programisty)

# File : index.php
if(preg_match('/^stage\.|\.dev$/', $_SERVER['HTTP_HOST'])) {
   $_SERVER['MAGE_IS_DEVELOPER_MODE'] = true;
}

tutaj Erik włącza ustawienie oparte na subdomenach, które można dostosować samodzielnie.

— Oğuz Çelikdemir
źródło

co to ma wspólnego z modułami do programowania?

— Bryan Ruiz

Drogi @ryan_ruiz, system Magento sprawdza, czy MAGE_IS_DEVELOPER_MODE jest aktywny czy nie. Sprawdź artykuł Alana. Tryb dewelopera Magento

— Oğuz Çelikdemir

co mówię, nie rozumiem, w jaki sposób odnosi się to do pytania. tryb programisty nie włącza ani nie wyłącza modułów, których używa.

— Bryan Ruiz

Bryan, jak określiłem w moim komentarzu, możesz dostosować kod jako swoją prośbę. Oczywiście surowy pomysł nie pasuje do żądania. Na przykład, jeśli napisałeś swoje rozszerzenie, zależy od parametru, możesz sprawdzić lub kontrolować powyżej fragmentu kodu!

— Oğuz Çelikdemir