SUPEE-10975 został wydany, byłoby wspaniale wiedzieć, jeśli ktoś napotka jakieś problemy podczas próby zastosowania tego, czy ten konflikt z najnowszą łatą, która dodaje obsługę 7.2?
Jak dotąd są to zmienione pliki, które widzę
app/code/core/Mage/Adminhtml/Block/Customer/Group/Edit.php
app/code/core/Mage/Adminhtml/Block/Newsletter/Template/Edit.php
app/code/core/Mage/Adminhtml/controllers/Cms/BlockController.php
app/code/core/Mage/Adminhtml/controllers/Customer/GroupController.php
app/code/core/Mage/Adminhtml/controllers/SitemapController.php
app/code/core/Mage/Adminhtml/controllers/System/BackupController.php
app/code/core/Mage/Captcha/Model/Observer.php
app/code/core/Mage/Captcha/Model/Zend.php
app/code/core/Mage/Captcha/etc/config.xml
app/code/core/Mage/Catalog/Model/Api2/Product/Image/Rest/Admin/V1.php
app/code/core/Mage/Catalog/Model/Product/Attribute/Media/Api.php
app/code/core/Mage/Cms/Model/Wysiwyg/Images/Storage.php
app/code/core/Mage/Core/etc/config.xml
app/code/core/Mage/Core/sql/core_setup/upgrade-1.6.0.7.1.1-1.6.0.7.1.2.php
app/code/core/Mage/Dataflow/Model/Convert/Container/Abstract.php
app/code/core/Mage/ImportExport/Model/Import/Entity/Customer.php
app/code/core/Mage/ImportExport/Model/Import/Entity/Customer/Address.php
app/code/core/Mage/Payment/etc/config.xml
app/code/core/Mage/Payment/etc/system.xml
app/code/core/Mage/Payment/sql/payment_setup/upgrade-1.6.0.0.1.1-1.6.0.0.1.2.php
app/code/core/Mage/Sendfriend/Block/Send.php
app/code/core/Mage/Wishlist/controllers/IndexController.php
app/code/core/Zend/Controller/Request/Http.php
app/design/adminhtml/default/default/template/cms/browser/content/files.phtml
app/design/frontend/base/default/layout/captcha.xml
app/design/frontend/base/default/template/wishlist/sharing.phtml
app/design/frontend/rwd/default/layout/page.xml
app/design/frontend/rwd/default/template/sendfriend/send.phtml
app/etc/modules/Mage_All.xml
app/etc/modules/Mage_Captcha.xml
app/locale/en_US/Mage_Wishlist.csv
js/lib/jquery/jquery-1.12.0.js
js/lib/jquery/jquery-1.12.0.min.js
js/lib/jquery/jquery-1.12.0.min.map
js/lib/jquery/jquery-1.12.1.js
js/lib/jquery/jquery-1.12.1.min.js
js/lib/jquery/jquery-1.12.1.min.map
Czy ktoś napotkał jakieś problemy z tymi zmianami?
parent::getDeleteUrl();
w app / code / core / Mage / Adminhtml / Block / Customer / Group / Edit.php przezreturn parent::getDeleteUrl();
Wystąpił problem z łatką 10975. Po pewnym dochodzeniu udało mi się znaleźć odpowiedź na pytanie, gdzie łata się psuje i dlaczego.
Podsumowując poniżej, sprawdź, czy poprawnie załatałeś SUPEE 9767 V2 . To jest podstawa mojego problemu.
Powyżej znajduje się błąd, który trafił w ten plik.
Błąd pochodzi z tej linii łatki.
Wersja wymieniona tutaj nie pasuje poprawnie z powodu ręcznego łatania
Ta łatka pochodzi z tej linii, której brakowało mi podczas ręcznego łatania.
źródło
Po pierwsze, przepraszam za duplikat odpowiedzi ereja , nie mogę komentować ani edytować z powodu mojej oceny reputacji.
Łata tworzy tutaj nowy plik:
app/code/core/Zend/Controller/Request/Http.php
Który jest dodawany w celu zastąpienia tego pliku:
lib/Zend/Controller/Request/Http.php
Problem dotyczy Magento w wersji 1.9.0.0 (EE 1.14.0.0):
Ta metoda :
Zostaje zastąpione w pliku Magento Core
app/code/core/Mage/Core/Controller/Request/Http.php
Co nie wymaga żadnych argumentów.
Odpala więc to ścisłe powiadomienie na dowolnym adresie URL, froncie i serwerze administracyjnym:
Strict Notice: Declaration of Mage_Core_Controller_Request_Http::getBaseUrl() should be compatible with Zend_Controller_Request_Http::getBaseUrl($raw = false) in /var/www/htdocs/app/code/core/Mage/Core/Controller/Request/Http.php on line 36
Jeśli ktoś wie, czy któraś z wersji V2 tej poprawki jest w drodze, daj mi znać.
Czekając na ich aktualizację, możesz przedefiniować metodę w następujący sposób
app/code/core/Mage/Core/Controller/Request/Http.php
:źródło
W wersji 1.8.1.0 po zastosowaniu tej poprawki musieliśmy również zmienić
app/code/core/Mage/Core/Controller/Request/Http.php::getBaseUrl()
funkcję naponieważ ta łatka dodaje
app/code/core/Zend/Controller/Request/Http.php
plik igetBaseUrl()
funkcja jest zadeklarowana parametrem$raw = false
.źródło
Mam problem z „Hunk # 1 FAILED at 28”
Odrzucenia są podobno zapisywane w config.xml.rej, ale ten plik nie istnieje, nie ma też opisu tego, która część skryptu zawiodła w moim oknie terminala. Zasadniczo łatka się nie udaje i nic nie wskazuje na to, dlaczego - przynajmniej nie dla takiego głupka jak ja!
Przy pierwszym uruchomieniu łatka próbowała usunąć trzy pliki jquery v 1.12.0, które nie istniały, zastąpiłem je i ponownie zastosowałem łatkę, ale teraz kończy się ona niepowodzeniem bez żadnego przydatnego opisu.
Magento 1.9.0.1 w pełni załatane oprócz aktualizacji kompatybilności z PHP 7.2, pozostanie niezałatowane, chyba że uda mi się to wypracować lub ktoś tutaj może dać mi wskazówkę (proszę!) Dzięki H
PS Nie jestem pewien, czy mój post jest niezgodny z wytycznymi SE, odpowiadam na oryginalne pytanie, ale proszę o pomoc.
źródło
Mage_Backup
Moduł zostanie wyłączony przez patch.Jest to wspomniane w oficjalnych informacjach o wydaniu ( https://devdocs.magento.com/guides/m1x/ce19-ee114/ce1.9_release-notes.html#ce19-1940 ).
Jednak sugerowane rozwiązanie ponownego włączenia jest nieprawidłowe:
(„Alternatywnie możesz użyć jednego z tych dwóch metod, aby włączyć tworzenie kopii zapasowych bazy danych”)
Aby w pełni włączyć tę funkcję, musisz użyć obu wymienionych metod.
źródło
Mogą wystąpić problemy z obsługą obliczania podatku prawidłową .
Jak zwykle w wielu krajach, nasz klient stosuje „ ceny zawierają podatki konfiguracji Magento ”.
Tak więc, po aktualizacji z 1.9.3.10 do 1.9.4.0, podatek został dodany do ogólnej sumy w kasie, oprócz cen produktów już zawierających podatki.
Śledziłem problem aż do zmiany konfiguracji w pliku app / code / core / Mage / Sales / etc / config.xml , gdzie „ msrp ” został dodany do węzła sales / quote / totals / shipping / after .
W informacjach o wydaniu nie znalazłem niczego dotyczącego MSRP i mam nadzieję, że jest to izolowana zmiana bez żadnych skutków ubocznych.
Moje rozwiązanie polegało na zmianie tego węzła z powrotem na jego pierwotną wartość „ suma częściowa, freeshipping, tax_subtotal ” bez „ msrp ”. Zrobiłem to w pliku etc / config.xml mojego własnego modułu.
źródło
Konkretny problem, ale jeśli wyłączyłeś Mage_Sendfriend (który wcześniej był modułem, możesz bezpiecznie wyłączyć), zgłosi błąd wyjątku.
źródło
Próbowałem uaktualnić z Magento CE 1.9.3.10 do 1.9.4.0 dzisiaj i miałem wiele błędów. Na szczęście nie zepsuło to instalacji. Po instalacji dostałem przerażające - wewnętrzny błąd serwera. Zostałem zablokowany i musiałem zresetować wszystkie moje uprawnienia do plików i folderów przez SSH wraz z usunięciem pliku Maintenance.flag. Następnie ponownie zindeksowałem i ponownie włączyłem pamięć podręczną. Dodatkowo musiałem przywrócić mój stary plik .htaccess w folderze Root and Download. Nie jestem pewien, jakie powinny być działania naprawcze, aby instalacja przebiegła pomyślnie. Zapomniałem skopiować tekstu z okna wiersza poleceń. Nie mogę więc opublikować wszystkich błędów. Widziałem niezgodne wiadomości.
źródło
Czy usunęli Zaplanowaną kopię zapasową?
Czy mam jakiś problem? Dlaczego w żadnej notatce nie ma o tym wzmianki? To wydaje się być wzorem dla Magento, w którym nie wspominają o takich zmianach, gdy pojawią się aktualizacje.
AKTUALIZACJA: wygląda na to, że całkowicie usunęli ją ze wszystkich wersji.
AKTUALIZACJA: musiałem wykonywać kopie zapasowe inaczej. Jeśli ktoś jest zainteresowany, zamieściłem tutaj niektóre polecenia CRON: Strategia tworzenia kopii zapasowych po SUPEE-10975?
źródło
W witrynie, w której poprzedni programista korzystał z niestandardowej konfiguracji wielu sklepów, zauważyliśmy problem. Wszystkie adresy URL sklepów innych niż sklep podstawowy to 404ing. Ustawił zmienną serwerową „HTTP_X_REWRITE_URL” / nagłówek HTTP, która zmieniła adres URL przetwarzany przez żądanie Magento.
Ta zmienna jest / była używana przez \ Zend_Controller_Request_Http :: setRequestUri (), ale nowa wersja w app / code / core / Zend / Controller / Request / Http.php już tego nie używa. Możliwe poprawki to:
Każdy z nich prawdopodobnie działałby, ale ten pierwszy prawdopodobnie nie będzie miał niezamierzonych konsekwencji, ponieważ działa bliżej poprzedniego systemu.
źródło
Określony błąd w metodzie płatności nie jest dostępny
Otrzymaliśmy wiele
The requested Payment Method is not available
błędów zgłoszonych przez Magento. Wszystkie zamówienia, w których była metoda płatności w zwrocie produktuccsave
, która została usunięta przez tę opłatę wconfig.xml
.Błąd jest generowany, ponieważ Magento szuka
$key
(w ccsave metoda płatności, w tym przypadku) przez sprawdzenie ścieżek XML:payment/ccsave/model
. Jeśli go nie znajdzie, zgłasza błąd. Więc właśnie zrobiliśmy agit checkout [insert supee commit]^ app/code/core/Mage/Payment/etc/config.xml
i nacisnęliśmy na master, aby naprawić błąd.app / code / core / Mage / Payment / Helper / Data.php
app / code / core / Mage / Payment / etc / config.xml
źródło
Zmiana na
app/code/core/Mage/Cms/Model/Wysiwyg/Images/Storage.php
przyczyny (inny) błąd, który nie został poprawnie wygenerowany ... szczegóły 1.9.4 nie wygenerowano poprawnie w mediach reżźródło
Prawdopodobnie nie, ale i tak wersja 1.9.4.0 już zaimplementowała.
źródło