NASZA OFERTA

co robimy ?

Refundacja NFZ jako metoda płatności w sklepie PrestaShop

Sklepy internetowe oferujące wyroby medyczne często wymagają rozwiązań wykraczających poza standardową sprzedaż internetową. Jednym z takich przypadków jest możliwość realizacji zamówienia z wykorzystaniem refundacji NFZ.

W sklepie opartym na PrestaShop można przygotować dedykowaną metodę płatności, która pozwala klientowi podczas składania zamówienia wybrać opcję „Refundacja NFZ”.

Jak może działać refundacja NFZ w PrestaShop?

Podczas standardowego procesu zakupowego klient wybiera produkty, podaje swoje dane, wskazuje sposób dostawy, a następnie przechodzi do wyboru płatności.

Wśród dostępnych metod może pojawić się dodatkowa opcja:

Refundacja NFZ

Po jej wybraniu klient otrzymuje informację, że zamówienie zostanie zweryfikowane przez pracownika sklepu pod kątem możliwości realizacji w ramach refundacji.

Przykładowy komunikat może wyglądać następująco:

Jeśli posiadasz refundację NFZ na wybrane produkty, wybierz ten rodzaj płatności. Nasz pracownik skontaktuje się z Tobą w celu weryfikacji danych oraz potwierdzenia możliwości realizacji zamówienia w ramach refundacji.

Dzięki temu klient może przejść przez cały proces zamówienia w sklepie internetowym, natomiast jego finalna realizacja odbywa się po sprawdzeniu wymaganych danych.

Dedykowana metoda płatności dla sklepów medycznych

Takie rozwiązanie może zostać dostosowane do konkretnego sposobu obsługi zamówień w danym sklepie. Możliwe jest między innymi przygotowanie:

• osobnej metody płatności „Refundacja NFZ”,
• dedykowanego opisu wyświetlanego podczas składania zamówienia,
• odpowiedniego statusu zamówienia w panelu PrestaShop,
• informacji dla klienta po złożeniu zamówienia,
• wiadomości e-mail związanych z zamówieniem refundowanym,
• procesu dalszej weryfikacji zamówienia przez pracownika sklepu.

Refundacja może funkcjonować równolegle ze standardowymi metodami płatności, takimi jak przelew bankowy, płatność przy odbiorze czy płatności elektroniczne.

PrestaShop pozwala na dostosowanie procesu zamówienia

Jedną z zalet PrestaShop jest możliwość rozbudowy procesu zakupowego o rozwiązania przygotowane pod konkretną działalność.

W przypadku sklepów medycznych standardowy mechanizm sprzedaży nie zawsze jest wystarczający. Zamówienie może wymagać dodatkowej weryfikacji dokumentów, uprawnień klienta lub poziomu przysługującej refundacji.

Dlatego odpowiednio przygotowana metoda Refundacja NFZ w PrestaShop może pełnić nie tylko funkcję płatności, ale również rozpocząć osobny proces obsługi zamówienia.

Refundacja NFZ bez rezygnowania ze sprzedaży internetowej

Wdrożenie takiego rozwiązania pozwala zachować wygodny dla klienta proces zakupowy. Klient może wybrać produkty i złożyć zamówienie przez sklep internetowy, a pracownik sklepu przejmuje później jego weryfikację i dalszą realizację.

Jest to szczególnie przydatne w sklepach oferujących między innymi wyroby medyczne, sprzęt stomijny, środki pomocnicze, produkty urologiczne czy inne produkty objęte refundacją.

Refundacja NFZ w sklepie PrestaShop jest możliwa

PrestaShop można dostosować do sprzedaży produktów objętych refundacją i przygotować specjalny wariant obsługi zamówienia przeznaczony dla klientów korzystających z NFZ.

Zakres wdrożenia może być dopasowany do procedur stosowanych przez konkretny sklep – od dedykowanej metody płatności po bardziej rozbudowaną obsługę i weryfikację zamówień refundowanych.

Cloaking po infekcji WordPressa – jak malware pokazuje Google tysiące fałszywych stron

Jeśli Twoja strona nagle straciła pozycje w Google, liczba zaindeksowanych adresów gwałtownie wzrosła albo w Google Search Console pojawiły się setki lub tysiące nieznanych podstron, problem nie zawsze leży w samym SEO.

Jedną z możliwych przyczyn jest infekcja wykorzystująca cloaking – mechanizm, który pokazuje użytkownikom prawidłową stronę, a robotom Google zupełnie inną zawartość.

To szczególnie niebezpieczne, ponieważ podczas zwykłego wejścia na stronę wszystko może wyglądać poprawnie. Dopiero porównanie odpowiedzi serwera dla standardowego użytkownika i Googlebota ujawnia, że wyszukiwarka otrzymuje spamerskie treści, produkty i tysiące wygenerowanych adresów URL.

Poniżej pokazujemy techniczny przykład takiej infekcji oraz sposób, w jaki udało się ustalić jej mechanizm działania.

Jednym z trudniejszych do wykrycia rodzajów infekcji strony internetowej jest cloaking, czyli zwracanie różnej zawartości w zależności od tego, kto odpytuje serwer.

W analizowanym przypadku zwykły użytkownik otrzymywał prawidłową stronę WordPress, natomiast Googlebot dostawał całkowicie inny dokument HTML – rozbudowany sklep z tysiącami linków do nieistniejących produktów i kategorii.

Dopiero analiza zainfekowanego pliku pozwoliła ustalić dokładny mechanizm działania.

Dwie różne wersje tej samej strony

Do diagnostyki wykonano dwa zapytania:

curl -L "$URL" -o normal.html

oraz:

curl -L -A "Googlebot/2.1 (+http://www.google.com/bot.html)" "$URL" -o googlebot.html

Różnica była bardzo duża.

Normalna odpowiedź zawierała właściwy kod WordPressa. Wersja zwracana Googlebotowi była wielokrotnie większa i zawierała strukturę obcego sklepu internetowego.

W przeanalizowanych plikach:

• normalna wersja zawierała około 115 linków,
• wersja dla Googlebota zawierała ponad 2400 linków,
• ponad 1400 z nich prowadziło do unikalnych adresów wewnętrznych.

To właśnie te linki mogły być następnie odkrywane przez Google i powodować gwałtowny wzrost liczby adresów widocznych w Google Search Console.

Źródło infekcji znajdowało się w pliku WordPressa

Złośliwy kod został umieszczony wewnątrz pliku należącego do WordPress Core.

Początek pliku wyglądał prawidłowo – znajdowały się tam standardowe informacje o wersji WordPressa. Dopiero w dalszej części został dopisany dodatkowy kod.

Pierwszy etap infekcji zawierał duży zaszyfrowany ciąg znaków.

Schemat działania wyglądał w uproszczeniu tak:

zakodowany ciąg
        ↓
Base64
        ↓
odszyfrowanie danych
        ↓
odtworzenie kodu PHP
        ↓
eval()

Payload nie został więc zapisany w pliku jako czytelny PHP. Zastosowano własną warstwę zaciemnienia wykorzystującą szyfrowanie blokowe zbliżone do XTEA, dzięki czemu proste wyszukiwanie charakterystycznych fragmentów złośliwego kodu mogło go nie wykryć.

Po odszyfrowaniu kod był wykonywany przez:

eval($payload);

To właśnie odszyfrowany drugi etap odpowiadał za cloaking.

Malware sprawdza User-Agent

Najciekawszym elementem infekcji okazała się analiza nagłówka:

User-Agent

Kod pobierał go bezpośrednio z:

$_SERVER['HTTP_USER_AGENT']

i porównywał z bardzo rozbudowaną listą robotów oraz narzędzi.

Na liście znajdowały się między innymi:

bingbot
AhrefsBot
SemrushBot
Screaming Frog
GPTBot
curl
wget
python-requests
HeadlessChrome
Selenium
Playwright
Puppeteer

Jeżeli któryś z tych ciągów został wykryty, złośliwy mechanizm nie był uruchamiany.

Co istotne – na tej liście nie znajdował się Googlebot.

To tłumaczy bardzo ważne zachowanie podczas diagnostyki.

Polecenie:

curl "$URL"

identyfikuje się domyślnie jako curl, więc infekcja celowo przestawała działać i administrator otrzymywał prawidłową stronę.

Natomiast:

curl -A "Googlebot/2.1 (+http://www.google.com/bot.html)" "$URL"

nie wpadało już w filtr ochronny malware i uruchamiało kolejny etap.

W efekcie to samo narzędzie mogło zwrócić dwie całkowicie różne strony tylko po zmianie User-Agent.

Decyzja o zwracanej treści była podejmowana zdalnie

Sam zainfekowany plik nie zawierał sklepu ani tysięcy produktów.

Pełnił funkcję loadera komunikującego się z zewnętrznym serwerem sterującym.

Po przejściu kontroli User-Agent malware tworzyło pakiet zawierający między innymi dane:

$_SERVER
$_POST

i wysyłało go do zewnętrznego serwera.

Oznaczało to, że serwer sterujący otrzymywał informacje o aktualnym żądaniu, m.in.:

User-Agent
Request URI
Host
metodę żądania
referer
adres IP widziany przez PHP
nagłówki HTTP
parametry POST

Na tej podstawie mógł zdecydować, jaką zawartość zwrócić.

Dzięki temu osoba kontrolująca infekcję mogła centralnie określić:

• komu pokazać prawidłowy WordPress,
• komu zwrócić spam,
• jaki sklep wygenerować,
• jakie produkty umieścić na stronie,
• jakie adresy URL utworzyć.

Zewnętrzna odpowiedź również była ukrywana

Odpowiedź serwera sterującego nie była przesyłana jako zwykły HTML.

Kod oczekiwał danych umieszczonych pomiędzy znacznikami:

<figure>...</figure>

Następnie wykonywał:

Base64 decode
        ↓
dekompresja
        ↓
JSON decode

Dopiero po tych operacjach otrzymywał właściwe instrukcje.

Jeżeli odpowiedź zawierała przygotowany HTML, malware wykonywało:

echo $html;
exit;

W tym momencie wykonywanie właściwego WordPressa było przerywane.

Googlebot dostawał więc nie zmodyfikowany fragment strony, lecz całkowicie zastępowaną odpowiedź HTML.

Mechanizm mógł również ustawić własny nagłówek HTTP przed wysłaniem treści.

Dlaczego Google zaczyna indeksować tysiące adresów?

Fałszywa strona dostarczana Googlebotowi zawierała ogromną liczbę linków wewnętrznych.

Robot wyszukiwarki widział więc strukturę przypominającą pełnoprawny sklep:

kategorie
    ↓
podkategorie
    ↓
produkty
    ↓
kolejne produkty

Googlebot odwiedzał znalezione linki.

Jeżeli również pod tymi adresami infekcja zwracała kolejne strony sklepu z dalszymi linkami, tworzyła się automatycznie rozrastająca struktura.

W ten sposób jedna infekcja może doprowadzić do pojawienia się w Google Search Console tysięcy, a nawet dziesiątek tysięcy nieistniejących URL-i.

Google ich nie generuje. Odkrywa je w HTML dostarczanym przez zainfekowany serwer.

Dlaczego infekcja była trudna do wykrycia?

Zastosowano jednocześnie kilka mechanizmów ukrywania:

1. malware znajdowało się wewnątrz prawidłowego pliku WordPressa,
2. właściwy kod był zaszyfrowany,
3. odszyfrowany kod był uruchamiany dynamicznie przez eval(),
4. curl i popularne narzędzia SEO były celowo wykluczane,
5. właściwa zawartość spamu była pobierana z zewnętrznego serwera,
6. serwer sterujący mógł zdecydować, komu wysłać spam,
7. pobierana odpowiedź była dodatkowo kompresowana i kodowana.

Dlatego samo wejście na stronę w przeglądarce albo wykonanie zwykłego:

curl "$URL"

mogło sugerować, że witryna działa całkowicie prawidłowo.

Jak diagnozować podobny przypadek?

Jeżeli Google Search Console nagle pokazuje tysiące nieznanych stron, jednym z pierwszych testów powinno być porównanie kilku User-Agentów:

curl -L "$URL" -o normal.html

curl -L -A "Googlebot/2.1 (+http://www.google.com/bot.html)" "$URL" -o googlebot.html

Następnie warto porównać:

diff normal.html googlebot.html

oraz wielkość obu plików:

ls -lh normal.html googlebot.html

Jeżeli różnice są ogromne, trzeba rozpocząć analizę po stronie PHP i serwera.

W przypadku WordPressa szczególnie istotne jest sprawdzenie integralności plików Core. Złośliwy kod może znajdować się nie tylko we wtyczce lub motywie, ale również bezpośrednio w plikach systemowych WordPressa.

Najważniejszy wniosek

W tym przypadku problem nie polegał na błędnej indeksacji Google.

Google prawidłowo indeksowało zawartość, którą otrzymywało od serwera.

Problemem był zainfekowany WordPress, który:

rozpoznawał sposób wejścia → kontaktował się z serwerem sterującym → pobierał przygotowaną treść → zastępował nią właściwą stronę → dostarczał Google tysiące linków do fikcyjnych podstron.

To dobry przykład, dlaczego przy nietypowym wzroście liczby stron w Google Search Console należy analizować nie tylko samą witrynę widoczną w przeglądarce, ale również surową odpowiedź HTTP zwracaną konkretnie Googlebotowi.

Nagły spadek pozycji, nietypowy wzrost liczby stron w Google Search Console czy pojawienie się obcych produktów w wynikach wyszukiwania może być sygnałem, że problem wykracza poza standardowe działania SEO.

W przypadku cloakingu samo poprawienie treści, meta tagów czy usunięcie adresów z Google nie rozwiąże problemu. Najpierw trzeba znaleźć źródło infekcji, usunąć złośliwy kod i sprawdzić, co serwer rzeczywiście zwraca Googlebotowi.

Jeżeli zauważyłeś podobne objawy na swojej stronie – spadki pozycji, tysiące nieznanych adresów w Google Search Console lub podejrzane wyniki wyszukiwania – skontaktuj się z nami.

Możemy przeanalizować stronę od strony technicznej i SEO, sprawdzić odpowiedzi serwera dla Googlebota, zweryfikować pliki WordPressa oraz ustalić, czy witryna nie została wykorzystana do generowania spamerskich treści.

AuthType Basic
AuthName "Strefa chroniona – tylko dla upoważnionych"
AuthUserFile /ścieżka/bezwzględna/do/.htpasswd
Require valid-user

admin:$2y$12$9vL3mPqR7sT5uV8wX9yZ0.ABCDEF1234567890ghijklmno
janek:$apr1$8fK9vL2m$Qj3kP9xL5vN7bR2tY6uI0
user2:{SHA}VBPuJHI7uixaa6LQGWx4s+5GKNE=

Symulator Google SERP według miasta – symulacja wyników lokalnych

Narzędzie Symulator Google SERP dla miasta pozwala sprawdzić, jak mogą wyglądać wyniki wyszukiwania Google dla konkretnej lokalizacji geograficznej – bez konieczności zmiany IP, używania VPN czy trybu incognito. To praktyczne rozwiązanie stworzone z myślą o specjalistach SEO, marketerach oraz właścicielach firm działających lokalnie.

Dzięki wykorzystaniu parametru uule (geo-lokalizacja) oraz wyłączeniu personalizacji wyników (pws=0), narzędzie generuje możliwie najczystszy i najbardziej obiektywny SERP, zbliżony do tego, jaki widzi użytkownik wyszukujący frazę w danym mieście.

Co możesz sprawdzić?

• widoczność strony w Local SEO dla wybranego miasta
• różnice w wynikach Google pomiędzy lokalizacjami
• pozycje stron lokalnych konkurentów
• sposób wyświetlania wyników dla różnych języków (hl) i krajów (gl)
• poprawność targetowania fraz typu „usługa + miasto”

Jak działa narzędzie?

1. Wpisz zapytanie (np. notariusz Katowice).
2. Wybierz miasto z listy (obsługiwane są miasta w Polsce i za granicą).
3. Ustaw kraj i język wyszukiwarki Google.
4. Otwórz wygenerowany link lub skopiuj go do dalszej analizy.

Dla kogo jest to narzędzie?

• agencji SEO i freelancerów
• firm pozycjonujących się lokalnie
• osób analizujących konkurencję w Google
• twórców treści i strategii pod Local Pack / Mapy Google

Pozycje (od prawej):  1   2   4   8   16  32  64  128
Bity:                b0  b1  b2  b3  b4  b5  b6  b7

1*128 + 1*64 + 0*32 + 0*16 + 1*8 + 0*4 + 1*2 + 0*1
= 128 + 64 + 8 + 2
= 202

a = 10101010
b = 11001100

a & b = 10001000

a | b = 11101110

a ^ b = 01100110

00010110 (22)
<< 1  →  00101100 (44)

00101100 (44)
>> 1  →  00010110 (22)

Podczas wysyłania e-maili w Mozilla Thunderbird możesz natknąć się na komunikat:

Wiadomość została wysłana, ale nie umieszczono jej kopii w folderze Wysłane z powodu błędów sieciowych lub dostępu do plików.
Można spróbować ponownie lub zapisać wiadomość lokalnie w „Lokalne foldery/Wysłane-biuro@pro-link.pl”.

Program sugeruje wtedy zapis wiadomości lokalnie w Lokalne foldery/Wysłane [adres email].
Najczęstszą przyczyną tego problemu nie jest sama sieć, ale nieprawidłowo wskazany folder „Wysłane” na serwerze IMAP.

Poniżej pokazuję, jak poprawnie ustawić folder – dokładnie tak, jak na załączonym screenie.

Dlaczego pojawia się ten błąd?

Krok 3. (Opcjonalnie) Sprawdź Archiwum i Szkice

Dla spójności warto też ustawić:

• Archiwum wiadomości przechowuj w: → Archiwum konta (IMAP)
• Szkice przechowuj w: → Szkice konta (IMAP)

Dzięki temu:

• cała poczta jest zsynchronizowana
• wiadomości są widoczne na innych urządzeniach (telefon, webmail)

Po zapisaniu zmian

1. Kliknij OK
2. Zamknij i ponownie uruchom Thunderbird
3. Wyślij testową wiadomość

Jeżeli wszystko jest poprawnie ustawione:

• błąd nie pojawi się ponownie
• kopia maila trafi do folderu Wysłane na serwerze
• wiadomość będzie widoczna także w webmailu

Podsumowanie

Komunikat o braku kopii w folderze „Wysłane” w Thunderbirdzie:

• nie oznacza, że mail się nie wysłał
• oznacza błędnie wskazany folder IMAP

Rozwiązanie jest proste:

Ustaw zapisywanie kopii w folderze „Wysłane” na serwerze, a nie lokalnie.

To jedna z najczęstszych i najbardziej mylących konfiguracji w Thunderbirdzie – a jednocześnie jedna z najłatwiejszych do naprawienia.

Jak naprawić podwójne puste linie w plikach po edycji w Visual Studio lub Windows

W pracy z kodem HTML, CSS czy JS często zdarza się, że plik edytowany w różnych środowiskach (np. Visual Studio, Notepad++, edytor FTP, IDE na Windows) zaczyna wyglądać dziwnie — linijki kodu są przedzielone pustymi liniami, a edytor wyświetla oznaczenia CRLF przy każdej z nich.

To problem, który dotyczy wielu webmasterów. Na szczęście jego rozwiązanie jest banalne.

W tym artykule wyjaśniam:

• skąd biorą się podwójne puste linie,
• jak działa CRLF / LF,
• jak to naprawić w Notepad++ jednym kliknięciem,
• jakie wyrażenie regularne usuwa wszystkie fałszywe puste linie z pliku.

Skąd biorą się puste linie w kodzie? Powód jest prosty: CR + CRLF

Windows używa końcówek linii CRLF, podczas gdy Linux używa LF.
Visual Studio potrafi dodatkowo nadpisać plik w formie:

CR LF CR LF

czyli podwójnych końców linii.
Notepad++ wyświetla wtedy kod w taki sposób:

<kod>      CRLF
           CRLF
<kod>      CRLF
           CRLF

Czyli każda linia ma „fałszywą pustą linię” pomiędzy.

Dla edytora to wygląda jak… puste linie, mimo że ich nie było w oryginale.

Jak łatwo naprawić podwójne linie w Notepad++?

1. Włącz widoczność końców linii

W menu:

Widok → Niewidoczne znaki → Pokaż końce linii

Zobaczysz oznaczenia:

• CRLF – Windows
• LF – Unix

Jeśli zobaczysz podwójne CRLF — problem potwierdzony.

2. Usuń puste linie wyrażeniem regularnym (najlepsza metoda)

Otwórz okno „Zamień” (Ctrl + H), zaznacz:

• Tryb: Wyrażenie regularne
• (nie zaznaczaj „Rozszerzony”)

I użyj tego:

Szukaj:

^\s*\r?\n

Zamień na:

(puste)

Kliknij Zamień wszystko.

Efekt:

• wszystkie fałszywe puste linie znikają,
• kod wraca do normalnej postaci,
• plik staje się czytelny i zgodny z IDE.

3. Jeśli chcesz pozostawić tylko jedną pustą linię (np. między sekcjami)

Użyj:

Szukaj:

(\r?\n){2,}

Zamień na:

\r\n

To zostawi jedną pustą linię zamiast wielu.

4. Konwersja końców linii (opcjonalnie)

Aby wymusić spójny format linii:

Format → Konwertuj na UNIX (LF)
lub
Format → Konwertuj na Windows (CRLF)

Po zapisaniu plik będzie jednolity.

Podsumowanie

Podwójne linie w Notepad++ nie wynikają z błędu edytora, tylko z nieprawidłowych końców linii w pliku — najczęściej po edycji w Visual Studio lub mieszaniu Windows/Unix.

Najprostsze rozwiązanie:

✔ zaznaczyć Wyrażenie regularne
✔ użyć ^\s*\r?\n
✔ usunąć wszystkie fałszywe puste linie

Dzięki temu można w kilka sekund wyczyścić duży plik i przywrócić normalne formatowanie kodu.

Pytania?

Kontakt