Forum PHP.pl

var coord_slug = lat.toString() + ',' + lng.toString();

Błędu? Jakiego błędu? Ja podtrzymuję to, co napisałem. Do napisania wydajnego crawlera ludzie wybierają inne niż php narzędzia: perl, python, javę, a nawet basha czy node.js. Rozumiem, że Ty jesteś z tych, co uważają, że programowanie zaczyna się w momencie napisania pierwszej linii kodu. Dla mnie programowanie to najpierw dogłębna analiza problemu i dobranie optymalnego (czyt. najlepszego) narzędzia do danej sytuacji, a nie pisanie w tym, w czym wydaje Ci się, że umiesz to zrobić i jakoś to będzie. Jak widać, jakoś to nie będzie. Jakoś to nie jakość, a forum jest od rozwiązywania problemów, a nie od ich mnożenia. Vokiel już Ci podał na tacy kilka możliwych rozwiązań, ale pewnie i tak będziesz się upierał przy swoim, że po co, że na co tak itd. Kończę tę jałową przepychankę, bo pojawiają się z Twojej strony argumenty z półki ad personam, co nigdy dla poważnej rozmowy niczego dobrego nie wróżyło. Ponownie pozdrawiam Cię i mimo wszystko życzę Ci powodzenia i owocnej nauki. Miłego dnia.

To teraz Ty się nie obraź, bo już mnie lekko irytujesz swoją impertynencją w tym i nie tylko w tym temacie. Najpierw sam sobie tworzysz wyimaginowany problem i wprowadzasz ludzi, którzy chcą się wspólnie zmóżdzyć z Tobą w błąd, nie podając pełnego kodu, a jedynie jakieś wyrywki. Pewnie. Domyślamy się wszyscy, że masz swój error handler... Patrz! unset zwalnia pamięć! Eureka! Następnie drążysz temat zarządzania pamięcią, na które to dość specyficzne w PHP zarządzanie nie masz totalnie żadnego wpływu i głową muru nie przebijesz, by na końcu określić czyjąś wypowiedź jako idiotyczną. Świetnie. Bawmy się tak dalej.
Użyj curla i nie płacz, że wolno działa, albo, że skrypt zżera za dużo pamięci. Przez podejście takich ludzi, jak Ty, o społeczności skupionej wokół języka PHP jeszcze długo będzie się mówić źle i tylko źle.
Zamiast skupić się na użyteczności i przydatności kodu, a przede wszystkim na jego wartości biznesowej, lecisz na forum ze sztucznie stworzonym problemem, którego tak naprawdę nie ma.
Założę się, że nawet nie raczyłeś sprawdzić curlowego rozwiązania, ale z góry zakładasz, że będzie działało znacznie wolniej.
Poczytaj o curl_multi_init, curl_multi_exec, wykonywaniu jednoczesnym żądań korzystając z tzw. gniazd nieblokujących, asynchronicznie. Jakby to dobrze napisać, to ten Twój crawlerek będzie zapierdzielał jeszcze szybciej niż z kupą niepotrzebnych wyjątków i skopiowanym całym backtracem zupełnie niepotrzebnie. Jak znasz odrobinę języka C to polecam lekturę źródeł PHP, tam naprawdę więcej nauczysz się o zarządzaniu pamięcią, niż poprzez takie eksperymenty.
Zresztą - nawet jeśli ten crawler będzie ciut wolniejszy, to chyba lepiej troszkę wolniej, ale niech w ogóle działa i nie wali błędami niż crawler, który po prostu nie działa...
PHP jeszcze Cię wiele razy zaskoczy. Idiotyczne są takie pseudo problemy. Tyle z mojej strony, trzymaj się, buziaki, pozdrówki. ps. nie jesteś w stanie mnie obrazić.

Jeśli masz znaczną ilość faili, to może przed próbą pobrania zawartości strony odczytaj samą wartość nagłówka HTTP i sprawdzaj czy to nie 404. mam na myśli coś takiego, pobierasz tylko nagłówki odpowiedzi serwera i wyciągasz sam kod http odpowiedzi:

[PHP] pobierz, plaintext 
protected function _getHeaderResponseCode($url) {
  $handle  = curl_init($url);
  curl_setopt($handle, CURLOPT_RETURNTRANSFER, true);
  curl_setopt($handle, CURLOPT_NOBODY, 1);
  $response = curl_exec($handle);
  $httpCode = curl_getinfo($handle, CURLINFO_HTTP_CODE);
  return $httpCode;
}
 
// ...
 
if ($this->_getHeaderResponseCode($url) != 404) {
  $data = file_get_contents($url);
}
 
// ...
[PHP] pobierz, plaintext 

Hmm... pół giga tekstu backtrace'u dla bieżącego i poprzedniego wyjątku + zawartość zmiennych lokalnych. To ile łącznie wyjątków zostało rzuconych? Ciężko w to uwierzyć, że to jest faktyczna przyczyna problemu.

Nie zrozumieliśmy się. Problemy ze zwalnianiem pamięci w pętlach w PHP są tak stare jak świat. Na podstawie tego fragmentu kodu trudno określić co dzieje się ze zmienną $html dalej i czy robisz tam jakiś unset czy nie. Użyj profilera, poświęć czas na analizę logu, poeksperymentuj z garbage collectorem. W sieci można znaleźć wiele tematów dotyczących problemów z pamięcią i używaniem takich funkcji jak json_decode, file_get_contents i funkcjami operującymi na xmlu. PHP generalnie średnio nadaje się do pisania rozwiązań działających na zasadzie demonów właśnie przez znane problemy ze zwalnianiem pamięci.

Wyciek pamięci, a wyczerpanie dozwolonego limitu zużycia pamięci dla skryptu to dwie różne kwestie. Zwróć uwagę na to, że nie podałeś warunku zakończenia pętli for, zatem nie dziw się, że mieli w nieskończoność aż dojdzie do limitu pamięci.

Napisał, że ma to w sekcji CDATA.

robert0770 - pokaż jakiś kod, żeby można było coś więcej wywnioskować. Jeśli ten dash (^) faktycznie jest w sekcji CDATA, to nie powinno generować takiego problemu. Polecam włączyć wyświetlanie błędów na początku skryptu:

[PHP] pobierz, plaintext 
error_reporting(E_ALL);
ini_set('display_errors', 'On');
[PHP] pobierz, plaintext 

Zasady, na które się powołujesz i o której pytasz to standardy kodowana znaków. Chodziło mi to, że standardy raczej nie opisują czegoś, co jest opcjonalne.

To Ty wysyłasz do przeglądarki w nagłówku content-type i charset i to Ty wymuszasz odpowiednie kodowanie, a interpretacja tego leży już po stronie przeglądarki klienta i nie powinna Cię martwić obsługa tego, bo to już od Ciebie nie zależy. Ty swoje zrobiłeś wysyłając odpowiedni charset i poprawnie kodując treść wiadomości.

Abstrahując od tego, że pytanie jest źle postawione, ponieważ plain text wcale nie musi zawierać znaków kontrolnych, aby spełniał definicję plain-textu

[źródło:] https://en.wikipedia.org/wiki/Plain_text
czyli - może, ale nie musi zawierać

Zarówno sposób zapisu, jak i interpretacji tego znaku zależy od użytego standardu kodowania (znaków). I właśnie te standardy opisują, jakiej sekwencji należy użyć, aby znak nowej linii był poprawnie interpretowany.
Podsumowując: nie ma jednej, jednolitej interpretacji, która obowiązuje wszędzie, natomiast są odpowiednie standardy dotyczące poprawnego kodowania znaków. Tabela reprezentacji znaków, akapit:

https://en.wikipedia.org/wiki/Newline

Jak widać, inaczej jest to zapisane w ASCII, inaczej w Unicode, jeszcze inaczej interpretują np. 8-bitowe Atari czy ZX Spectrum

Można to porównać do np. języków europejskich, gdzie piwo to zarówno beer, jak i: cerveza, pivo, piwo, μπυρα, alut, öl itd. itp. W zależności od kraju, w którym się znajdujesz - chodzi o to, żeby kupić piwo, a jak to zapisać to już jest sprawa wtórna i zmartwienie spragnionego melanżownika. Pani w sklepie zrozumie

Do tego stopnia że wklejam Wam link do artykułu, z 2006 roku, ale wydaje się być ciągle aktualny: http://www.onlamp.com/pub/a/onlamp/2006/08...g-newlines.html

Nie twierdzę, że jest inaczej i nikogo nie traktuje, jak debila. Drążcie sobie, jak działa new line.

Dostałeś już odpowiedzi na nurtujące Cię problemy dotyczące "standardów" zapisu nowej linii. Nie widzę dalszego sensu drążenia tematu, ale co taki klepacz kodu, jak ja może na ten temat wiedzieć...

Nie oceniaj pochopnie, poza tym - nie rozumiem Cię, ani Twoich problemów.

"\r\n" Nie masz poważniejszych, prawdziwych problemów ?

Jak widzisz widełki 3k-6k, to mów, że chcesz 6k. To jest pułapka, takie dogadywanie się, że za rok, że będzie - najważniejsze, co dostajesz na papierze od pierwszego dnia pracy. Niektóre firmy obiecują złote góry, aby zwabić developera, na gębę ustalisz, że np. za rok masz mieć nie 4k, a 6k, a po roku już nikt nie będzie o takich ustnych ustaleniach pamiętał, dlatego nie istotne jest, co dostaniesz, za rok czy za pół roku, bo prawdopodobnie nic nie dostaniesz, a istotne jest to, co masz ustalone na już, na teraz, dziś.

Spróbuj:

[SQL] pobierz, plaintext 
SELECT nazwa_koloru, CAST(HEX(kolor) AS UNSIGNED) AS kolor FROM `kolory`;
[SQL] pobierz, plaintext 

To już nawet nie o to chodzi czy coś jest poufne i ważne dla nas czy nie - po prostu ta zielona kłódka stała się już jakiś czas temu takim standardem, który miło byłoby widzieć tutaj na forum.

Witajcie,

Czy ktoś kiedyś naprawi logowanie po ssl?
https://forum.php.pl/logowanie.html

Chciałbym, aby moje dane były bezpieczne. Mogę dorzucić się do kosztów zakupu certyfikatu.

To ładnie się nazywało: przypomnienie o płatności. 😂 Generalnie największą lipę mieliśmy jak algorytm sklasyfikował zamówienie jako nieopłacone a ono wisiało na statusie czeka na status płatności tylko jeszcze nie spłynął request zwrotny. To taki stan pośredni zanim bramka zwróci Ci faktyczny status. Rozwiązane to zostało poprzez umieszczenie na końcu informacji że jeśli płatność została już dokonana to prosimy zignorować niniejszą wiadomość, ale i tak zdarzali się zbulwersowani klienci, którzy wydzwaniali z pretensjami na infolinię ale to temat na osobny wątek 😉 Podsumowując: każde rozwiązanie ma swoje wady o zalety.

Temat był analizowany dość długo przez dział prawny w kontekście prawa europejskiego, bo sklep wielojęzyczny, rynki europejskie, jeśli zamówienie wisi na etapie bramki płatności to zgody masz już zaakceptowane, a regulamin odpowiednio napisany. Sama treść maila nie jest żadną stroną produktu jest to link do koszyka który klient sam wyklikał składając zamówienie i jest to traktowane jako forma przypomnienia. Obowiązek podania istniejącego adresu email i obowiązku rejestracji w serwisie stoi w zaakceptowanym regulaminie. W przypadku zamówień które nie dotarły jeszcze do zewnętrznego serwisu płatności ale klient podał swój email przerobiliśmy checkout tak, aby chexkbox zgody pojawił się możliwie jak najwcześniej i nie ma w tym nic niedozwolonego. Zgoda na newsletter to inna para kaloszy.

W jednym z projektów rozwiązaliśmy takie nieopłacone zamówienia właśnie mechanizmem porzuconych koszyków. Po mniej więcej dobie od wychwycenia takiego nieopłaconego zamówienia wysyłamy mail do klienta z linkiem do wypełnionego przez niego koszyka. Właściwie to taki klient nic więcej nie musi robić, wystarczy kliknąć link i ponownie wybrać metodę płatności i opłacić zamówienie. Mega ułatwienie dla ludzi, nie trzeba nic ponownie wypełniać. Mocno polecam takie rozwiązanie. Pamiętam że początkowo były wątpliwości natury prawnej, jednak finalnie wystarczyło dodać dwie rzeczy: 1. to że wysyłasz maila bo klient podając swoje dane osobowe w checkoucie wyraził zamiar zakupu produktów oraz 2. że niniejszy mail nie stanowi oferty handlowej.

Przypomniałeś mi jeszcze o istotnym mechanizmie odzyskiwania porzuconych koszyków: mega spoko rozwiązanie, znam prawdziwy przypadek na rynku holenderskim po wdrożeniu tego sprzedaż wzrosła prawie o 20% Nie chciało mi się wierzyć że takie wdrożenie aż tak podbije sprzedaż, bo ludzie są leniwi, zapominalscy itd. Powodzenia!

Ps. Pomyśl też nad wdrożeniem bloga zintegrowanego że sklepem, system ocen produktów (gwiazdki i moderowane komentarze), jakiś system ticketowy typu zendesk. To naprawdę działa tylko trzeba na start trochę wydać i poczekać na efekty.

Jeśli na potrzeby własne implementujesz, to zaleta jest taka, że można do woli eksperymentować. Wszystko zależy od tego, jak słuszne (i czy) przyjmiesz założenia, co weźmiesz pod uwagę oraz - przede wszystkim - jaki chcesz uzyskać rezultat? Rekomendacje to nie wszystko, co można klientom zaoferować. Częściowy efekt wzrostu sprzedaży można osiągnąć stosując np. sprzedaż krzyżową, up-selling (gorsza karma - lepsza karma dla kota). Z kolei zaimplementowanie zestawów produktów również może przynieść wymierne korzyści, ludzie są przyzwyczajeni, że w pakiecie/zestawie jest taniej. Kilka prac wcześniej spotkałem się z ciekawą socjotechniką sprzedaży, mianowicie: never-ending promocja. Wystawiasz na stronie wszędzie widoczny timer, który odlicza, np. do końca promocji zostało jeszcze tyle i tyle godzin:minut:sekund i to sobie tak tyka. Niby każdy wie, że to lipa, ale finalnie mechanizm dość znacznie wpłynął na sprzedaż, wiem, ponieważ salesi porównywali wyniki sprzed wdrożenia z wynikami z kilku miesięcy po i wzrost był odczuwalny. Pomyśl też np. o tym, że jak klient zapisze się do Twojego newslettera, to z automatu dostanie jednorazowy kupon rabatowy do wykorzystania z datą ważności np. 30 dni. Podobny kupon można wdrożyć też po dokonaniu dowolnego zakupu. Klient czuje się wtedy doceniony, a lojalny klient - nagrodzony za zakup. Pieczesz dwie pieczenie na jednym: budujesz bazę potencjalnych lojalnych klientów, a jak robisz wyprzedaż, to szybka akcja marketingowo-mailowa i masz zwiększony ruch w sklepie. Siłą rzeczy prędzej czy później przekłada się to na wyniki sprzedaży czy tego chcesz czy nie.

Miałem do czynienia z wdrożeniem rekomendacji. Nie wiem czy nie zostanie to potraktowane jako reklama, ale był to Quartic.

Co do zasad działania algorytmów, to niestety, ale firmy tworzące takie rozwiązania strzegą swoich mechanizmów i wcale się nie dziwię. Generalnie mogę powiedzieć jeszcze, że pod uwagę brane były takie dane, które musieliśmy dostarczyć tej firmie:

- feed produktów zawierający oprócz podstawowych danych produktów takich jak: nazwa, cena, kategorie, opis również takie dane: obrazki (zdjęcia produktów), ilość zamówień na produkt
- wiem, że algorytm analizuje również zdjęcia produktów, gdyż jednym z kryteriów produktów podobnych jest np. dominująca kolorystyka zdjęcia produktu
- do tego dochodzą miesięczne dane sprzedażowe oraz dane dot. konwersji

Jakoś to po tamtej stronie jest zlepiane w całość, oczywiście wiele też zależy od branży, której wdrożenie dotyczy. Rekomendacje inaczej będą działać jeśli np. sprzedajesz reprodukcje obrazów, a inaczej jeśli Twoja branża do części zamienne do urządzeń AGD.
Wiem, że też jednym z kryteriów, dość ważnym była przynależność produktów do (pod)kategorii i np. dopasowanie: produkt podobny, z tej samej kategorii lub podkategorii ze zdjęciem o dominującej kolorystyce, jak produkt główny. Do tego dochodzą kryteria z analizy sprzedaży czyli np. to co wymieniłem wcześniej plus np. produkty najczęściej kupowane w tej danej kategorii lub produkty z innej kategorii, ale takie, które również były najczęściej kupowane (i oglądane) z tym produktem bieżącym.

Co do wdrożenia, to skrypty komunikujące się z nimi były triggerowane na stronach:
- produktu (product view)
- kategorii
- koszyka
- finalna strona success page

Myślę, że taki algorytm jest dość skomplikowany i bierze pod uwagę wiele aspektów: zarówno dane dot. wyświetleń pojedynczych produktów przez jednego visitora + produkty najczęściej kupowane wraz z tym, który visitor ogląda w danej chwili + powiązane (podobne kategorie - np. najlepiej sprzedający się produkt z innej, jednak podobnej kategorii) + cross-sell / up-sell który sam ustawisz sobie + analizuje podobne kolorystycznie zdjęcia produktów + analizuje poprzednie zamówienia + wyniki analizy podobnych nazw/tytułów produktów. Nie wiem czy nie lepiej będzie dla Ciebie zlecić taką gotową kampanię rekomendacji, generalnie dobrze to działało, jedyny minus to, że koszty wdrożenia to % od Twojej sprzedaży, w przypadku większych sklepów można z nimi negocjować, ale ogólnie fajnie to działa.