Tag: php

Dzisiaj na kilku stronach działających na WordPressie wdrażaliśmy pewną wtyczkę. Niby nic nadzwyczajnego, ale wtyczka ta nie pochodzi(ła) z np. z repozytorium WordPress.org, a bezpośrednio z serwisu GitHub. Tym samym jej aktualizację trzeba było oprzeć nie o standardowe mechanizmy aktualizacji WordPressa, ale o mechanizmy Gita. A, że strony te działały na jednym serwerze, to, zamiast multiplikować kod wtyczki (i tym samym procedurę aktualizacji) postanowiłem skorzystać z linków symbolicznych.

Pobieranie (płatnych) wtyczek i motywów do WordPressa z „nieoficjalnych stron” (nie tylko) w kontekście bezpieczeństwa

Kilka dni temu, podczas rozmowy ze znajomymi pojawił się temat płatnych motywów i wtyczek do WordPressa, które – w pewnym uproszczeniu – często „muszą” być wydawane na licencji jak WordPress, czyli GPL. Ma to takie znaczenie, że teoretycznie tak zakupiony produkt (wtyczka, motyw) może być dalej legalnie dystrybuowany. Korzystają z tego (trochę, bo często tam i tak nikt licencjami się nie przejmuje) różne serwisy, z których można pobrać bezpłatnie płatne wersje motywów i wtyczek. Ale jak to w życiu bywa – na koniec dnia każdy biznes musi (na czymś) zarabiać, również ten „piracki”.

Languages remover for Divi Builder, czyli pozbywamy się „kiepskich” tłumaczeń z Divi Buildera (również w motywach Divi i Extra)

Kilka miesięcy temu napisałem o problemach ze zmianą domyślnego języka w WordPressie, gdy wyłączone są tłumaczenia w ustawieniach motywu Divi i Extra. Z racji tego, że wyłączenie takie przy obecnie dystrybuowanych tłumaczeniach wydaje się wręcz niezbędne (komputerowe tłumaczenie kontekstowe to nadal komputerowe, nieważne, ile by tam „sztucznej inteligencji” marketing wpompował), ale zarazem jego wyłączenie wpływało na język samego WordPressa i innych wtyczek (język angielski zamiast polskiego) postanowiłem, że muszę coś z tym zrobić… Zwłaszcza że ekipa z Elegant Themes jakby uparła się na to maszynowe tłumaczenie, pomimo „sugestii” użytkowników.

Strona ZTM w nowej odsłonie, do tego portal Warszawski Transport Publiczny na WordPressie, czyli kolejna medialna gównoburza

Patryk | 06.12.2019 | Wyrazy: 1008, znaki: 5723 | Bezpieczeństwo, Biznes, Felietony, Hosting i serwery, Inne, Internet, Media, Oprogramowanie, Polska, Prasówka, Strony internetowe (WWW), Technologia, Wiadomości, WordPress, Wydarzenia | 0 |

Wczoraj po internecie rozlała się informacja o tym, że Warszawski Transport Publiczny (strona WTP przejęła przy okazji część „zadań” od strony ZTM, która także się zmieniła) ma nową stronę. To akurat zapewne dostrzegł (prawie) każdy, kto w ostatnich dniach chciał choćby sprawdzić rozkład. No ładne to to nie jest, ale to nie wygląd czy nawet (okrojenie) funkcjonalności stoi za tym „rozgłosem” (a być może szkoda). Media – a za nimi niestety niektórzy politycy – podchwycili temat od absurdalnej strony, pokazując – moim zdaniem – swoją totalną niewiedzę w temacie, jak i to, że nieprzypadkowo mówi się, że dziennikarzy już właściwie nie ma, bo zastąpili ich pracownicy mediów…

Jest już WordPress 5.3 Kirk (i WooCommerce 3.8), a wraz z nim weryfikacja adresu e-mail administratora

Wczoraj miała miejsce premiera najnowszej odsłony WordPressa (5.3 Kirk) oraz WooCommerce (3.8). Zastanawiałem się, czy o tym pisać, ale uznałem, że raczej nie ma takiej potrzeby. Mamy nowy motyw domyślny (Twenty Twenty), wsparcie dla nadchodzącego PHP 7.4, a większość poprawek „dla cywili” sprowadza się do usprawnień w Guntenbergu, którego sam nie używam. Ale w WordPressie 5.3 pojawiła się też jedna opcja, która, choć moim zdaniem potrzebna, to – jak już widzę po reakcjach niektórych znajomych i klientów – może wywoływać lekkie zamieszanie/zdziwienie…

Gdy po zmianie PHP z wersji 5.6 na 7.2/7.3 zamiast strony (na WordPressie) widzisz biały ekran (WSoD) sprawdź moduły PHP

Jakiś czas temu przez formularz kontaktowy zwróciła się do mnie pewna dziewczyna od bloga kulinarnego, że „coś tam, coś tam na hostingu” i teraz zamiast strony (WordPress) wyświetla jej się biały ekran śmierci. I choć od niedawna WordPress posiada zabezpieczenie przed tego typu problemami (nie zawsze działa, ale jest… ;-)), to na stronie działał WordPress w wersji 4.9.x, a więc ostatniej sprzed ery Gutenberga (nadal wspierany). Z racji tego, że nie było czasu do stracenia, ustaliliśmy kwotę wynagrodzenia i przystąpiłem do reanimacji kulinarnego WordPressa…

Wykrywanie urządzeń mobilnych w języku PHP (biblioteka Mobile Detect) i w WordPressie (wbudowana funkcja)

Właśnie skończyłem prace nad jednym z modułów projektu, nad którym pracuję, a w którym to module ważna jest funkcja „wyłapywania” urządzeń mobilnych (głównie telefony, tablety z racji większego ekranu nie były już tak istotne). Operację taką w PHP można wykonać choćby za pomocą funkcji preg_match(), która może wyłapywać – po słowach kluczowych w nagłówku HTTP_USER_AGENT – przeglądarkę/system, i na bazie spróbować rozpoznać, czy mamy do czynienia z urządzeniem mobilnym. Jest to dość skuteczna metoda, tyle tylko, że wymaga ciągłego śledzenia „rynku przeglądarek mobilnych”, co w tym przypadku nie wchodzi(ło) w grę. Dlatego postanowiłem skorzystać z gotowca. A właściwie, to 2 gotowców…

CloudFlare i Page Rules w praktyce, czyli historia pewnego ataku na skrypt/stronę logowania do WordPressa (WooCommerce)

Patryk | 06.08.2019 | Wyrazy: 720, znaki: 4454 | Bezpieczeństwo, Biznes, Domeny internetowe, eCommerce, Hosting i serwery, Internet, Oprogramowanie, Polecane, Poradniki, Strony internetowe (WWW), Technologia, Technologia, WooCommerce, WordPress | 3 |

W drugiej połowie lipca, w piękny piątkowy poranek, po porannym spacerze z psami usiadłem do komputera, bo na mojej administracyjnej skrzynce e-mail pojawiły się powiadomienia m.in. ze skryptu SysWatch, oraz z aplikacji Monit, czyli narzędzi, które wykorzystuje do monitorowania zasobów serwera. A z racji tego, że z kufelkiem tego dnia siedział obok kolega, który coś tam kupa (rozróżnia hosting od domeny ;-)), to pomyślałem, że od razu pokaże mu, jak można w relatywnie prosty sposób zdiagnozować źródło i wyeliminować problem.

Ukazała się stabilna wersja systemu Debian 10 Buster

Od jakiegoś już czasu przymierzam się do napisania nowego poradnika dotyczącego konfiguracji webserwera (Nginx + PHP 7.x + MySQL), bo od czasu pierwszej edycji minęło już naprawdę sporo czasu. W międzyczasie pojawiały się kolejne artykuły czy aktualizacje, ale… Z napisaniem tego artykułu czekałem na oficjalną premierę Debiana 10 (Buster), tak by poradnik miał szansę być aktualny przez dłuższy czas. Poradnik jeszcze przede mną, ale warto odnotować, że wczoraj premierę miał system Debian 10 w wersji stabilnej.

Nginx i błąd „address already in use” podczas startu usługi

Dziś, podczas rutynowej aktualizacji serwerów VPS, zgodnie ze wskazaniami systemu – wykonałałem restart kolejnych serwerów. Wszystkie uruchomiły się prawidłowo, na prawie wszystkich uruchomiły się również wszystkie wymagane usługi. Problem był z jednym serwerem – nie wystartowała usługa webserwera Nginx. Skrypt działający na serwerze i podejmujące proste próby naprawy w takiej sytuacji (głównie restart usług + monit) też nie był w stanie automatycznie uporać się z problemem. Po zalogowaniu się do konsoli po SSH i ręcznej próbie startu usługi otrzymałem komunikat, który już kiedyś widziałem, choć tym razem przyczyna musiała być inna…

Poważna podatność we wtyczce WP Live Chat Support (również w wersji „pro”) do WordPressa, którą należy pilnie zaktualizować

Nie będę leciał tzw. „clickbaitami”, czyli tytułami, które mają nakłonić jak największą liczbę osób do odwiedzenia danej strony w stylu „trwają masowe ataki na strony oparte na WordPressie”, czy też nie mniej alarmistycznie: „strony na WordPress zagrożone – wymagane działanie”, z których niczego konkretnego się nie dowiecie. Ale faktem jest, że jeśli korzystacie ze wtyczki WP Live Chat Support (również w wersji płatnej, czyli „pro”) do WordPressa, to czym prędzej dokonajcie aktualizacji, bo zagrożenie faktycznie jest dość poważne.

Prosty sposób na własny tryb konserwacji (przerwy technicznej) w WordPressie – bez dodatkowych wtyczek, tylko odrobina kodu

Koleżanka poprosiła mnie o pomoc – potrzebuje aktywować coś na wzór „sprzedażowego trybu konserwacji” w swoim WordPressie. W uproszczeniu polegać ma to na tym, że chciałaby przełączyć stronę w tryb konserwacji, tak by osoby niezalogowane widziały stronę zaślepkę, a resztę stron mogłyby (tymczasowo) oglądać tylko osoby zalogowane. Pozornie nic trudnego, tego typu wtyczek (maintenance mode) jest pełno. Jednak koleżanka chciała, by tymczasowa strona mogła korzystać ze wszystkich dostępnych dobrodziejstw jej WordPressa, łącznie z page builderem…

Tryb awaryjny w WordPressie (5.2+), czyli awaryjny dostęp do panelu zarządzania (WP-Admin), gdy coś pójdzie nie tak (zamiast WSoD)

WordPress 5.2 (Jaco) przyniósł nam nie tylko mechanizm sprawdzający stan witryny (niedawno pisałem, jak go troszkę w razie potrzeby „oszukać”), ale też tryb awaryjny (recovery mode), który w przypadku usterki/błędu wtyczki lub motywu pozowała uzyskać dostęp do panelu zarządzania (WP-Admin), by spróbować odratować stronę…

Prosty sposób na proste testy A/B w WordPressie, gdy motyw, page builder czy wtyczka nic takiego nie oferują

Odezwał się do mnie kolega, że gdzieś wyczytał, że na stronie sprzedażowej (landing page, sales page, squeeze page) warto eksperymentować m.in. z wyglądem formularza kontaktowego. Ciężko mu nie przyznać racji, bo czasem nawet zmiana koloru przycisku potrafi znacznie zwiększyć konwersję. W tym zadaniu dobrze sprawdzają się testy A/B, które pozwalają generować różne wersje strony dla różnych odwiedzających (oczywiście testy A/B to nie tylko zmiana koloru przycisku ;-)). Problem kolegi wynikał z tego, że jego motyw, jak i wtyczka do kontaktów takiej opcji nie posiadają…

Stan witryny w WordPressie (5.2+) to przydatna opcja, ale warto wiedzieć, że/jak można wyłączyć poszczególne testy

Wraz z niedawną premierą WordPressa 5.2 (Jaco) zadebiutował też mechanizm sprawdzający stan witryny/strony, dzięki czemu nawet mniej zaawansowana osoba może w prosty sposób sprawdzić, czy strona działa prawidłowo i spełnia wszystkie wymagania WordPressa. Z naprawą/korektą w większości przypadków pewnie już tak łatwo nie będzie, i tu już może być wymagana trochę bardziej techniczna wiedza, ale zawsze od czegoś trzeba zacząć. Są jednak sytuacje, gdy niekoniecznie chcemy tego typu testem dzielić się np. z potencjalnym klientem…

Brak tagu zamykającego blok języka PHP nie tylko nie musi być błędem, ale często wręcz może być koniecznością

Poprosił mnie znajomy o przygotowanie wtyczki do WordPressa na bazie jednego z opublikowanych poradników, bo chciał w niej zawrzeć pewne modyfikacje (dodatkowe opcje) i nie bardzo wiedział jak się do tego zabrać. Z racji tego, że była to dość specyficzna potrzeba, uznałem, że nie będę tworzył powiązanego z nią poradnika, a najszybciej będzie, jak po prostu mu to napiszę, zamiast tłumaczyć co i jak… Przygotowałem wtyczkę, wysłałem do znajomego, ten postanowił (słusznie) do niej zajrzeć, by zobaczyć co i jak zrobiłem. Przy tej okazji zwrócił mi uwagę, że choć wtyczka działa, to chyba znalazł w niej mały błąd…

Zadebiutował WordPress 5.2 „Jaco”, a wraz z nim funkcja wp_body_open(), z nowym hakiem „wp_body_open”

Dziś zadebiutował publicznie WordPress 5.2 „Jaco” (od Jaco Pastorius), który przyniósł kilka zmian, jak to w przypadku aktualizacji bywa. Wśród zmian mamy dodatkowe strony związane z usługą „Site Health” (opcja, która pojawiła się wraz z 5.1), gdzie możemy sprawdzić stan witryny („stan witryny pokazuje krytyczne informacje na temat konfiguracji WordPressa i innych elementów, które wymagają twojej uwagi”), oraz uzyskać dodatkowe informacje o samej stronie („strona pokazuje każdy szczegół konfiguracji twojej witryny opartej o system WordPress”). Poprawiono też mechanizm zarządzania i kontrolowania ewentualnych błędów PHP, wraz ze specjalnym trybem awaryjnym (recovery mode). Ale dla mnie chyba najistotniejszą zmiana jest nowa funkcja, a wraz z nią nowy filtr, dzięki któremu można będzie w prosty sposób dodać kod zaraz za znacznikiem <body>.

Dodawanie ikon do strony internetowej (np. do menu) na przykładzie Font Awesome 5 (i Dashicons) i WordPressa

Będzie o ikonach (nie tylko) w menu, czyli temacie trochę pochodnym ostatnich zmian na Webinsider.pl – ikony w menu były chyba od zawsze, ale niedawno dorobiły się ich wszystkie pozycje (w menu głównym), i od razu w statystykach widzę, że jest dużo większe zainteresowanie poszczególnymi pozycjami. Dostałem też kilka pytań, jak takie ikony wdrożyć, stąd ten artykuł…

Kompleksowe podejście do wysyłania wiadomości e-mail z WordPressa, czyli co zrobić by wszystko było jak trzeba

Patryk | 02.02.2019 | Wyrazy: 866, znaki: 5307 | Bezpieczeństwo, Biznes, eCommerce, Hosting i serwery, Internet, Oprogramowanie, Poczta e-mail, Polecane, Poradniki, Strony internetowe (WWW), Technologia, Technologia, WooCommerce, WordPress | 2 |

O wysyłaniu wiadomości e-mail z WordPressa już pisałem, tak samo, na temat wysyłania ogólnie, czy to bezpośrednio z serwera (MSMTP), czy z dowolnej strony w PHP (PHPMailer). Ale w ostatnich dniach mam sporo wejść z wyszukiwarek na hasła typu „WordPress wysyłanie e-maili”, czy „motyw Divi wysyłanie e-maili”. Dlatego pomyślałem, że stworzę kolejny artykuł, w którym postaram się całościowo przedstawić to zagadnienie.

Usuwanie wersji skryptów i stylów (CSS) z adresów plików wczytywanych w nagłówku przez WordPressa

Kolega postanowił poszukać Świętego Graala, przynajmniej jeśli o chodzi o szybkość jego strony internetowej w teście Google PageSpeed Insights. Oczywiście życzę powodzenia, nawet jeśli to często sztuka dla sztuki. Przy tej okazji zapytał, jak w WordPressie najprościej i bez dodatkowych wtyczek (wydajność ;-)) wywalić z adresów ładowanych plików CSS i skryptów (JavaScript) dodawane automatycznie argumenty z wersją – czy to samego WordPressa czy wtyczki lub motywu. Ponoć ma lepiej cache dzięki temu działać, a tym samym w teście wpadnie dodatkowy punkt lub może nawet dwa…

Tag: php

Wszystkie

Akcja społeczna

Zostańmy przyjaciółmi

Kanały RSS

InfoWidget