Będzie kiedyś uruchomiona opcja wysyłania SMSów z poziomu LMSa przez serwersms.pl?
W dniu 13.02.2015 09:00, wojtekca napisał(a):
Będzie kiedyś uruchomiona opcja wysyłania SMSów z poziomu LMSa przez serwersms.pl?
https://github.com/lmsgit/lms/blob/master/lib/LMS.class.php i szukamy "serwersms".
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.
Czy jest to gdzieś przewidziane? Jak to dodać wedle "filozofi git" i pluginów. potrzebna jest dodatkowa pozycja bazy.
PS. Jakiś czas temu poddałem problem z prędkością działania. Czy wszyscy wymieniają sprzęt na nowszy i zwiększają czasy wykonania żeby nowa wersja mogła działać?
Dnia 2015-02-13, pią o godzinie 09:17 +0100, Tomasz Chiliński pisze:
W dniu 13.02.2015 09:00, wojtekca napisał(a):
Będzie kiedyś uruchomiona opcja wysyłania SMSów z poziomu LMSa przez serwersms.pl?
https://github.com/lmsgit/lms/blob/master/lib/LMS.class.php i szukamy "serwersms".
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?
Czy jest to gdzieś przewidziane? Jak to dodać wedle "filozofi git" i pluginów. potrzebna jest dodatkowa pozycja bazy.
PS. Jakiś czas temu poddałem problem z prędkością działania. Czy wszyscy wymieniają sprzęt na nowszy i zwiększają czasy wykonania żeby nowa wersja mogła działać?
Skoro nikt inny nie zgłaszał problemu, tzn. że problem występuje tylko u Ciebie.
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?
W starszej wersji LMS to przerabiałem. Wystarczy poczytać dokumentację, tak działa serwersms. Często zwraca status skolejkowany.
Czy jest to gdzieś przewidziane? Jak to dodać wedle "filozofi git" i pluginów. potrzebna jest dodatkowa pozycja bazy.
PS. Jakiś czas temu poddałem problem z prędkością działania. Czy wszyscy wymieniają sprzęt na nowszy i zwiększają czasy wykonania żeby nowa wersja mogła działać?
Skoro nikt inny nie zgłaszał problemu, tzn. że problem występuje tylko u Ciebie.
Dla osoby która wcześniej odpowiedziała, rozwiązaniem było wydłużenie dopuszczalnego czasu wykonywania. Jeżeli więcej osób tak do tego podchodzi to problem jest a ludzie traktują go jak prawo natury.
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.
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". A propos czasu wykonania - potraktuj kod profilerem i zobaczysz co w Twojej instalacji zabiera najwięcej czasu wykonania.
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.
A propos czasu wykonania - potraktuj kod profilerem i zobaczysz co w Twojej instalacji zabiera najwięcej czasu wykonania.
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.
Dnia 2015-02-13, pią o godzinie 11:46 +0100, Tomasz Chiliński pisze:
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.
Wracam do kluczowego pytania, jak dodanie czegoś takiego miało by wyglądać za pomocą pluginów żeby nie było kłopotów z łataniem itp. Sprawdzanie czy sms doszedł w perl sprowadza się do my $response = $ua->get($sms_url.'?login='.$sms_user.'&haslo='.$sms_password.'&akcja=sprawdz_sms&smsid='.$sms->{'smsid'});
Ale w bazie trzeba mieć smsid i dodatkowy status. Zrobienie pacza który będzie "nie kompatybilny" to chwila moment. Jak dodać przez pluginy?
A propos czasu wykonania - potraktuj kod profilerem i zobaczysz co w Twojej instalacji zabiera najwięcej czasu wykonania.
W dniu 13.02.2015 12:10, Sylwester Zdanowski napisał(a):
Dnia 2015-02-13, pią o godzinie 11:46 +0100, Tomasz Chiliński pisze:
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.
Wracam do kluczowego pytania, jak dodanie czegoś takiego miało by wyglądać za pomocą pluginów żeby nie było kłopotów z łataniem itp. Sprawdzanie czy sms doszedł w perl sprowadza się do my $response = $ua->get($sms_url.'?login='.$sms_user.'&haslo='.$sms_password.'&akcja=sprawdz_sms&smsid='.$sms->{'smsid'});
Ale w bazie trzeba mieć smsid i dodatkowy status. Zrobienie pacza który będzie "nie kompatybilny" to chwila moment. Jak dodać przez pluginy?
Masz: https://github.com/lmsgit/lms/blob/master/lib/LMS.class.php#L1676 więc w kodzie pluginu można podpiąć się pod hook 'sms_send_before'. W lib/plugins/example.php masz przykładowy kod pluginu, którego szkielet można wykorzystać do napisania obsługi dowolnego dostawcy usługi wysyłki sms w oparciu o wspomniany przeze mnie hook. Tyle, że akurat standardowo obsługiwane api sms lepiej byłoby wzbogacić o dodatkowe funkcje (jak np. potwierdzenia odebrania) bezpośrednio w kodzie metody SendSMS(...) klasy LMS.
Dnia 2015-02-13, pią o godzinie 12:19 +0100, Tomasz Chiliński pisze:
Masz: https://github.com/lmsgit/lms/blob/master/lib/LMS.class.php#L1676 więc w kodzie pluginu można podpiąć się pod hook 'sms_send_before'. W lib/plugins/example.php masz przykładowy kod pluginu, którego szkielet można wykorzystać do napisania obsługi dowolnego dostawcy usługi wysyłki sms w oparciu o wspomniany przeze mnie hook.
Dzięki będzie dobre miejsce żeby ogarnąć mechanizm. Ale do zrobienia sprawdzania potrzebne jest dodanie do bazy danych dodatkowej tablicy z smsid nadawanymi przez smsserwer. normalnie dodane było by to przez upgrade a dla dodatków?
Tyle, że akurat standardowo obsługiwane api sms lepiej byłoby wzbogacić o dodatkowe funkcje (jak np. potwierdzenia odebrania) bezpośrednio w kodzie metody SendSMS(...) klasy LMS.
To już pozostaje dla panujących nam programistów ;)
Modyfikacje bazy danych związane z pluginami raczej trzeba przeprowadzić ręcznie przy każdej instalacji. Metodę SendSMS możnaby w przyszłości zaprojektować tak, aby było możliwe jej przesłonięcie w łatwy sposób z wnętrza pluginu, w tej chwili jest to raczej niemożliwe.
W dniu 13.02.2015 o 15:09, Sylwester Zdanowski pisze:
Dnia 2015-02-13, pią o godzinie 12:19 +0100, Tomasz Chiliński pisze:
Masz: https://github.com/lmsgit/lms/blob/master/lib/LMS.class.php#L1676 więc w kodzie pluginu można podpiąć się pod hook 'sms_send_before'. W lib/plugins/example.php masz przykładowy kod pluginu, którego szkielet można wykorzystać do napisania obsługi dowolnego dostawcy usługi wysyłki sms w oparciu o wspomniany przeze mnie hook.
Dzięki będzie dobre miejsce żeby ogarnąć mechanizm. Ale do zrobienia sprawdzania potrzebne jest dodanie do bazy danych dodatkowej tablicy z smsid nadawanymi przez smsserwer. normalnie dodane było by to przez upgrade a dla dodatków?
Tyle, że akurat standardowo obsługiwane api sms lepiej byłoby wzbogacić o dodatkowe funkcje (jak np. potwierdzenia odebrania) bezpośrednio w kodzie metody SendSMS(...) klasy LMS.
To już pozostaje dla panujących nam programistów ;)
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
Z bazą danych to chyba w inetLMS(?) widziałem rozwiązanie gdzie zmiany oryginalne LMS mają swój nr wersji a inet idą równolegle. Jak długo równoległe zmiany dodają tablicę a nie modyfikują istniejących mogą robić za część pluginów. Nie można wykorzystać tego pomysłu?
Zrobić sprawdzania wersji bazy lms i wersji lms-plugin a oznaczenie plików datą zmienić na oznaczenie nazwą pluginu? Jest to wykonalne w kodzie ale czy do zaakceptowania jako część LMS?
Przy okazji na zbliżonym froncie. :) Można jakąś podpowiedź jak dla kompatybilności dodawać nowe moduły? A jeszcze lepiej "podmieniać" istniejące części html? np listę dokumentów klienta na listę dokumentów z dodatkowymi opcjami (ikonami)
Dnia 2015-02-13, pią o godzinie 19:25 +0100, Maciej Lew pisze:
Modyfikacje bazy danych związane z pluginami raczej trzeba przeprowadzić ręcznie przy każdej instalacji. Metodę SendSMS możnaby w przyszłości zaprojektować tak, aby było możliwe jej przesłonięcie w łatwy sposób z wnętrza pluginu, w tej chwili jest to raczej niemożliwe.
W dniu 13.02.2015 o 15:09, Sylwester Zdanowski pisze:
Dnia 2015-02-13, pią o godzinie 12:19 +0100, Tomasz Chiliński pisze:
Masz: https://github.com/lmsgit/lms/blob/master/lib/LMS.class.php#L1676 więc w kodzie pluginu można podpiąć się pod hook 'sms_send_before'. W lib/plugins/example.php masz przykładowy kod pluginu, którego szkielet można wykorzystać do napisania obsługi dowolnego dostawcy usługi wysyłki sms w oparciu o wspomniany przeze mnie hook.
Dzięki będzie dobre miejsce żeby ogarnąć mechanizm. Ale do zrobienia sprawdzania potrzebne jest dodanie do bazy danych dodatkowej tablicy z smsid nadawanymi przez smsserwer. normalnie dodane było by to przez upgrade a dla dodatków?
Tyle, że akurat standardowo obsługiwane api sms lepiej byłoby wzbogacić o dodatkowe funkcje (jak np. potwierdzenia odebrania) bezpośrednio w kodzie metody SendSMS(...) klasy LMS.
To już pozostaje dla panujących nam programistów ;)
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
uczestnicy (4)
-
Maciej Lew -
Sylwester Zdanowski -
Tomasz Chiliński -
wojtekca