W dniu 13.02.2015 11:42, Sylwester Zdanowski napisał(a):
Dnia 2015-02-13, pią o godzinie 11:26 +0100, Tomasz Chiliński pisze:
W dniu 13.02.2015 11:17, Sylwester Zdanowski napisał(a):
Dnia 2015-02-13, pią o godzinie 11:14 +0100, Sylwester Zdanowski pisze:
Dnia 2015-02-13, pią o godzinie 10:47 +0100, Tomasz Chiliński pisze:
W dniu 13.02.2015 10:26, Sylwester Zdanowski napisał(a):
Z ciekawości przejrzałem wysyłkę serwersms. O ile widzę przy skolejkowaniu ustawiany jest błąd. Ale skolejkowanie często jest zwracane przez serwer a sms dochodzi chwilę później. Mam na to rozwiązanie w postaci zapisywania id wiadomości i późniejszego odświeżania statusu.
Skąd ten wniosek?
Powtarzam pytanie "Jak to dodać wedle "filozofi git" i pluginów. potrzebna jest dodatkowa pozycja bazy." Wnioskuję że trzeba dorzucić łaskawie panującym twórcą LMS do sakiewki.
Chyba za dużo używasz Debiana ;-)
A propos "serwersms" - polecam spojrzeć na: https://github.com/lmsgit/lms/blob/master/lib/LMS.class.php#L1885 (wiersz 1885). Jest negacja preg_match(...), więc błąd wystąpi w sytuacji, gdy serwersms zwróci coś innego niż "skolejkowane".
Prawda :) tyle że to odwraca sytuację. Skolejkowanie oznacza że jeszcze nie wiemy czy się uda czy nie w efekcie jeżeli przyjmiemy to jako brak błędu i tak nie dowiemy się później co się stało z sms. W efekcie jedynym pewnym rozwiązaniem jest sprawdzanie statusów. Jeżeli pamięć nie myli serwersms potrafi też wysyłać informację na wskazany adres.
Do tego mógłby być przydatny dodatkowy status wiadomości w lms - powiedzmy MSG_RECEIVED.
A propos czasu wykonania - potraktuj kod profilerem i zobaczysz co w Twojej instalacji zabiera najwięcej czasu wykonania.