Gość

Cwany ruch, strzelam, że z 90% licencji to same Forum, więc dla większości oznacza to drastyczną podwyżkę przedłużenia licencji z 90$ na 199$ - ponad 2x tyle. Dla osób prowadzących fora hobbystycznie, nie zarabiając na tym, już wydatek ~360 zł na rok był kłopotliwy, ale można było powiedzmy zaryzykować i brać raz na rok, mając forum jakiś czas bez wsparcia, ale oszczędzając połowę. A teraz jakieś 800 zł i albo płacisz, albo tracisz licencję. A cena nowej licencji to jest po prostu totalny odlot 499$ - na dziś to są ponad 2 tysie. Dla porównania: XenForo - 160$ + 55$ co roku Woltlab - 119,99€ + 59,99€ co roku phpBB - 0 Ja wiem, że za dodatkowe aplikacje u konkurencji także wychodzi drożej, ale sądzę, że większość ich nie potrzebuje i teraz dostaną je "na siłę", niektórzy mogą nawet nie być gotowi pod kątem zasobów serwera. IPS chyba lubi tak co wersję coś dowalić. Nadal uważam, że IPB 4 to jest ogromny regres pod kątem konfigurowalności w porównaniu do tego, co było w IPB 3. I jeszcze w prezencie zaoranie wtyczek, gdzie kilka mam i używam, np. chatbox. Pewnie autorzy musieliby stworzyć nowe (jeśli będzie się dało), a za robotę od nowa będzie trzeba zapłacić od nowa i kolejny wydatek. Oczywiście dobrze rozumiem, że pozostanie na starej licencji oznacza brak dostępu do IPB 5 i będzie można co najwyżej siedzieć na IPB 4, aż go nie odetną od aktualizacji? Na Clouda w życiu bym się nie zdecydował - danej mojego forum nagle należą do nich, hostowane w USA, więc nawet nie wiadomo jak to się ma do RODO/przepisów i pewnie chcąc od nich uciec - odzyskać danych się nie da albo jest to maksymalnie utrudnione. Jeśli coś się nie zmieni, dla mniejszych for to się nie kalkuluje i prędzej przejdę np. na Xena - w cenie rocznego przedłużenia IPS mam nową licencję Xena + parę groszy na dodatki

Rikki z IPS skomentował, że ma to dotyczyć także wideo, ale czy wideo załadowanego, czy YT, nie wiadomo. Nie wiem też, czy będzie się ładować przy scrollowaniu, czy może dopiero po kliknięciu. Druga opcja byłaby w moim przypadku lepsza, bo tak to w sumie user dostanie to samo, tylko na raty, scrollując. Także średnio... Ale jeśli nic innego nikt nie widział, to chyba pozostanie czekać na to...

Trochę tak, znalazłem takie coś: https://invisioncommunity.com/files/file/8186-lazy-load-videos/ Ale kurka 15 dolców + upgrade'y (co pewnie byłoby z czasem konieczne, gdy wyjdzie nowy IPB, np. 4.4), poza tym nie do końca to by załatwiło sprawę, bo w sumie przy przewijaniu strony i tak user dostanie tym w twarz, tylko na raty. Poza tym coś Invision ćwierkało, że chcą dodać lazy loading, tylko chyba w komunikacie nie było nic o wideo/YT. Dlatego z tym się wstrzymałem, nic innego mi za bardzo nie wpadło w oko ?

Silnik forum pewnie tak Ale problem jest dla użytkowników, bo gdy temat polega na wstawianiu wideo i w widoku jest np. ze 70 klipów, to na słabszych komputerach próba jednoczesnego załadowania takiej ilości osadzonych YT doprowadza przeglądarki do zwiech i CPU do wrzenia

W IPB 3 była fajna opcja, że można było ograniczyć ilość osadzonych YT w poście i kolejne wstawiały się jako linki. W IPB 4 nic takiego nie widzę, nie widzę też wtyczki do tego. Ktoś się spotkał z taką możliwością?

Mnie rozwala brak informacji przy poście, że jest zgłoszony - w 3.4.x była informacja przy poście, w 4.x pozostaje się przebijać przez panel zgłoszeń, nie można zamknąć zgłoszenia prosto z poziomu zgłoszonego postu. Cofanie się w rozwoju... Inny kwiatek, ale na styku serwer-IPB: przy ładowaniu spolszczenia IPB pobiera listę obsługiwanych lokalizacji z serwera (WTF? po co na litość boską!), w efekcie nie mogłem podać pl_PL, bo na lokalnym WAMP nie zgłaszało się. Weszło samo pl, ale zaowocowało takim oto mistrzostwem: Zaraz przyjdzie mi faktura na 25 USD i słabo mi się robi na samą myśl...

Od pre-release mijają blisko półtora roku. Teraz jest dostępna 4.1.8.1, zapowiadana jest 4.1.9 (mimo istotnych poprawek bezpieczeństwa jeszcze nie udostępniona). Co zmieniło się przez rok od mojego ostatniego postu? Niewiele Każdemu zdarza się pomylić, ale trwać w błędzie 2 lata, to już chyba tylko IPS umie. Nowe podejście do konwersji: - zwiększyła się znacznie ilość zapytań, które trzeba sobie wykonać samemu ręcznie. I to nie problem, tylko że część z nich jest totalnie zbędna. Na 16 zapytań, które przy konwersji musiałem zrobić sam tak 8 była zbędna (0 affected rows), wypadałoby sprawdzić przed zawracaniem gitary, czy w ogóle SELECT zwraca cokolwiek co wymaga wykonania zapytania. Ale to tylko świadczy o równie ambitnym poziomie programistycznym dalej. - nowością od ostatniego razu było uruchomienie konwertera do UTF8, bo tym razem o ile baza mu się spodobała, to instalator stwierdził, że collation (nie znam tłumaczenia) mu nie pasuje. Mielił chyba z pół godziny bez żadnej informacji o postępie operacji, na koniec nie wrócił do instalatora, który musiałem odpalić od nowa... - w wersji 4.1.9 jest zapowiadane to, co zauważyłem już dobry rok temu: Performance improvements to areas which perform large updates on the members table (for example, when editing permissions). I zgłaszałem to, zostałem olany. Niestety inni też zgłaszali i wreszcie okazało się, że jednak się da tam coś poprawić... - nadal po konwersji z 3.4.x forum jest niby używalne, ale praktycznie nieużywalne, bo w tle wisi ogromna ilość zadań, która albo będzie się mieliła 100 lat, albo wywoła się je na siłę zajeżdżając serwer (robienie konwersji większego forum gdziekolwiek poza localhostem polecam tylko jak ktoś ma dedyka) - nadal zadania owe są ekstremalnie wolne (przebudowa postów trwa wieki, milion postów spokojnie 24h) oraz są tam zadania no po prostu od czapy. Po kiego grzyba przebudowywać tytuły tematów? Nie można było tego zrobić od razu? Co może być takiego w tytułach, że aż trzeba je osobno przebudowywać (i to między IPB 3.4.x, a 4.x)? Do tego to zadanie jest zawieszone aż nie skończy się przebudowa postów - nadal owe zadania mogą się nieoczekiwanie wywoływać od nowa po zmianie jakichś ustawień, strach cokolwiek ruszyć, bo jak mi dowali przebudowę postów, to w zasadzie forum jest do wyłączenia na 24h - nadal spośród opcji z 3.4.x większości brak i zapewne nie będzie - strumienie aktywności są totalnie niezrozumiałe, a ich ustawianie jest dla przeciętnego usera nie do przejścia - przekombinowane i niejasne, komplikacja do granic rozsądku rzeczy, która w 3.4.x była mega prosta. Niby więcej możliwości, ale większości to do niczego nie potrzebne, a komplikuje to, co było do tej pory łatwo osiągalne dla wszystkich. - w bugtrackerze w tej chwili wisi... 669 bugów (tylko statusy Pending i Future, pominąłem te rozwiązane w nieopublikowanym 4.1.9). Nawet zakładając, że 80% z tego to są bzdety, to nadal jest ich w pierona. Ja bym nie narzekał, gdyby to było darmowe phpBB, ale płacę za to do wafla ciężkiego i wymagam. Jak nie ogarniają, to niech zrobią open source.

Ataki spamu na oficjalne forum widziałem w ostatnim okresie wielokrotnie i niestety niezbyt dobrze to świadczy o IPS4 - jeśli sam producent nie jest w stanie zabezpieczyć swojego forum, to troszkę to niepokoi...

Spolszczenie wrzucone tam nie jest autorstwa osoby, która je wrzuciła, wystarcza zajrzeć do środka, pojawiają się linki do oryginalnego źródła. Dodatkowo jest nieaktualne. A poza tym to offtopic

Ciekawie czyta się forum IPS. Wynika z tego, że 4.0 wydali, ale tak - od tego tygodnia mają mieć człowieka, który będzie pracować nad wydajnością (no w samą porę ), powiadomienia mają zostać udoskonalone "wkrótce", do zadań w tle, które na dużych forach mielą po konwersji w nieskończoność dorobią "inteligencję", która będzie określać, czy można tymi zadaniami bardziej zajechać serwer. Ogólnie jest wesoło. Chyba chcieli pójść śladem vBulletin, co udało się całkiem wzorowo IMHO Co do samej konwersji - a tak zabawowo puściłem. Jeśli nie wywali w kosmos w trakcie konwersji, to zadania w tle są najgorsze, bo owszem - niby forum może działać bez ich ukończenia, tylko co z tego, jeśli bez ukończenia przebudowy postów treści postów mają rozwalone formatowanie i wszelkie BBCodes (osobno konwersja sygnatur - to samo). Forum wygląda jak po solidnym walnięciu bomby atomowej. Procesy w tle można przyśpieszyć wymuszając ich wywołanie "nie w tle", ale i tak duże forum to wiele godzin (od wersji beta jest poprawa, wtedy niektórym te zadania szły wiele... dni). Szczerze - trudno mi zrozumieć jakie zmiany wprowadzono, że aż taka czasochłonna przebudowa jest konieczna oraz czy na pewno to przemyślano na etapie implementacji. Już szybciej szła konwersja z phpBB do IPB 3.4.7 niż z IPB 3.4.7 do IPB 4.0 o_O Do tego już zauważyłem, że są operacje i zmiany w ustawieniach, które mogą doprowadzić do ponownego odpalenia się wybranych zadań. Na szczęście nie przebudowy postów, ale muszę to dopiero wybadać. Jak wyżej - 4.0 dla nowych boardów może OK, starsze powinny to dobrze przemyśleć, bo to droga w jedną stronę (jedna osoba - szaleniec - odważyła się na przesiadkę na etapie RC - i straciła kilka dni postów z bazy, bo pozostało się cofać do 3.4.7). Dodatkowo - pod nóż poszło naprawdę sporo opcji. Ekipa IPS tłumaczy, że były rzadko używane, za skomplikowane dla administratorów ( http://i1.kym-cdn.com/photos/images/original/000/173/576/Wat8.jpg ) oraz że jakby co, to mogą zaimplementować w przyszłości, ale jeśli ktoś z czegoś korzysta, to nie będzie przecież czekał na jakąś tam bliżej nieokreśloną przyszłość... Jeśli rzucę liczbą 30% opcji wyciętych, to myślę, że wiele się nie pomylę. Źle rozwiązana opcja zapisu ustawień uprawnień może prowadzić do problemów na wielu serwerach, jeśli forum ma wiele działów i kategorii (także na dHostingu, bo sam na nim siedzę). Po prostu się nie zapiszą, wyklikasz, dajesz OK, wracasz, a tu większość pól odznaczona. W sumie sprawę zbagatelizowano, podsumowując, że dodadzą informację, że się nie da z winy serwera... W efekcie musiałem ustawić uprawnienia na localhoście, zmieniając wcześniej limity w php.ini, bo na serwerze bym nawet nie pierdnął. Nie wiem po co były betatesty i RC, jeśli poprawiano wybrane bugi wybierane wg niezrozumiałego klucza. Admini - uważajcie, mina. Trzeba czekać na aktualizacje.

No nic, siadłem do tego i zrobiłem kilka eksperymentów. Wyszło tak, że zmiany kodu na latin2 i utf8 nie pomogły (w pierwszym przypadku bez zmian - znaki zapytania, w drugim - znaki jak w bazie, nieczytelne), ale pomogła zmiana na latin1. Ponieważ jednak jak pisałem wyżej zmiana w kodzie nie podoba mi się, wycofałem to i dałem latin1 w sql_charset w conf_global.php. Wydaje się, że działa, na razie robię resynchronizację wszystkiego i czyszczę cache, ale już widzę, że jest raczej dobrze. Po skończonej kompletnej resynchronizacji jeszcze wszystko posprawdzam i potwierdzę. Ta zmiana jeszcze ujdzie, bo jest w konfiguracji, więc nie będzie się wysypywać przy aktualizacjach. Czy ktoś jest w stanie wyjaśnić: 1) Dlaczego mam wybierać latin1, choć ani nic nie wskazuje, że baza jest tak zapisana, ani nie są tak ustawione sposoby kodowania znaków w bazie i porozumiewania się z nią, a sam wygląd bazy jest taki sam jak lokalnie, gdzie żadnego latin1 nie wybieram i to działa? 2) Czy to ustawienie nie niesie ryzyka, że forum nie będzie poprawnie obsługiwać unicode, pogubi nietypowe znaki z postów itp.?

Dzięki, byłem tam już, ale nie chcemy robić modyfikacji w samym IPB, bo później będziemy się z tym męczyć przy każdej aktualizacji (albo przynajmniej przy tych, które ten plik podmienią). Poza tym jest to nienormalne mając na uwadze, że lokalnie działa bez takich kombinacji. Musi istnieć jakaś logiczna przyczyna...

To będzie długa historia... Przekonałem znajomego do przejścia na IPB z phpBB3 i siedliśmy we dwóch wyposażeni w piwo do konwersji. Kolejność: - zrzucamy pliki phpBB ze starego forum oraz bazę na localhost (xampp), baza w phpBB3 jest w latin2_general_ci, a porównywanie znaków dla połączenia - utf8_general_ci, po wejściu phpMyAdminem widać polskie znaki normalnie - dla pewności odpalamy stare forum z localhosta (poprawiając połączenie z bazą) - działa, są polskie znaki - robimy bazę pod IPB 3.4.7, znaki na utf8_unicode_ci - instalujemy lokalnie IPB, zaraz po instalacji startujemy konwersję robiąc wszystko kolejno jak każą - po konwersji lokalnie wszystko jest OK, są polskie znaki na forum, natomiast w phpMyAdminie wygląda to w stylu: "Z ciekawoÅ›ci sam zobaczÄ™." - samo IPB po konwersji w pliku conf_global.php sql_charset ma pusty, nie ma tam utf8, ale wszystko działa, więc się tym nie przejmujemy - robimy kopię skonwertowanej bazy (znaki w pliku z kopią są takie jak w phpMyAdminie) - na serwerze tworzymy bazę (utf8_unicode_ci, czyli jak lokalnie, porównywanie znaków dla połączenia też to samo - utf8_general_ci) - idziemy zgodnie z poradnikiem http://forum.invisionize.pl/topic/1470-przenoszenie-forum-na-inny-serwer/(bo w sumie teraz przenosimy z lokala na serwer), czyli ładujemy pliki, poprawiamy połączenie z bazą w conf_global.php - kontrola ścieżek, czyszczenie szablonów, cache itp. Byłem niemal pewny, że to zagra, ale nic z tego. Choć baza ma te same kodowanie znaków, porównywanie znaków i wygląda tak samo jak lokalna patrząc przez phpMyAdmina, to forum wyświetla się bez polskich znaków (zamiast tego są ? normalne lub w czarnych rombach) Spróbowałem dopisać utf8 w conf_global.php (co jednak wydaje mi się bez sensu, przecież lokalnie działa bez tego), to forum wyświetla znaki prosto jak są widoczne przez phpMyAdmina, czyli np.: "Z ciekawoÅ›ci sam zobaczÄ™." Dodatkowo czasami sypie błędami w stylu: Warning: preg_replace(): Compilation failed: invalid UTF-8 string at offset 17 Warning: Cannot modify header information - headers already sent by Na próbę zrobiliśmy inaczej i postawiliśmy czyste IPB na serwerze, a na koniec tylko przepięliśmy bazę na zaimportowaną, ale też nic z tego, ten sam efekt. Kolejna próba - wstawiliśmy nowy post na obydwa fora - lokalne, gdzie polskie znaki są OK oraz to na serwerze, gdzie są wywalone. Nowe posty w obydwu miejscach wyświetlają się OK, ale dostaliśmy różne efekty widoczne w phpMyAdminie (cały czas mamy te same metody porównywania znaków) post o treści: śćźćół 汉字[漢字] phpMyAdmin lokalny: śćźćóŠ汉字[漢字] phpMyAdmin serwer: ĹÄĹşÄóŠćąĺ­[柢ĺ­] Jeszcze jeden eksperyment - dograliśmy spolszczenie. Lokalnie OK, a na serwerze OK, jeśli nie wywali warningów podanych u góry - wtedy spolszczenie ładuje się też bez polskich znaków. Jeśli to coś podpowie, to serwer to dHosting, domyślnie tworzy się tam bazy danych przez ich web admina i mają metodę porównywania latin2, którą zmieniliśmy przed ładowaniem bazy na utf8, bo w końcu taką mamy lokalnie, więc czemu na serwerze miałaby być inna? Co tu się odwala? Dzieje się jakiś kosmos, proszę o naprowadzenie co zrobić inaczej. Nic nie jest problemem, możemy pyknąć wszystko od początku, łącznie z konwersją, byleby efekt końcowy był prawidłowy. Jedyne ograniczenie - nie na serwerze, baza jednak trochę ma, lokalnie mieli się to dość długo, nie widzę szans na zrobienie konwersji online. Jednocześnie nie chcemy nic zmieniać w samym kodzie IPB (np. parametry połączenia), żeby później nam to nie ciążyło przy aktualizacjach - jeśli to działa lokalnie to przecież musi jakoś działać też z serwera? Nie jestem pewny, czy to jednak wina konwersji (choć przecież działa na koniec po konwersji lokalnie), czy też przenosin?

To może być związane, więc... przed momentem przyszedł mi jakiś plik SECRET.zip (w środku plik tekstowy). Opisany jako (DP31) Secret Project + powiadomienie na maila. Ponieważ miało nie być plików do pobrania, a także się nie zgłaszałem, to dla pewności pytam, czy to tak ma być

Niestety nie pomogło na temat emotikon - wszystkie z przekonwertowanej bazy są otoczone "<!--" i "-->". Porozglądam się po sieci, czy ktoś się z czymś takim spotkał Dzięki za pomoc

Jak teraz piszę na bieżąco - pojawiają się - jedynie wszystkie stare wyparowały. Mały problem jest też z cytatami - w ramkach tytuł jest taki: QUOTE ("nick":losowy ciąg 6 znaków) To co jest kursywą raczej nie powinno się pokazywać? Zapuszczę jeszcze raz tego naprawiacza postów...

Dziwne - przebudowywałem już posty (w ogóle wykonałem przebudowę wszystkiego z poziomu ACP), ale spróbuję jeszcze raz - może coś nie wyszło? Prawdę mówiąc miałem dodatkowe emoty wrzucone (czyli ponad standard w phpBB), ale brak zarówno tych dodatkowych (to mogę zrozumieć) jak i standardowych. Pobawię się tym w nocy

Nie da się wyedytować tego wstydliwego postu powyżej, więc ku przestrodze dla innych konwertujących na przyszłość: Przyczyna braku możliwości zalogowania u mnie była banalna. W archiwum z konwerterem są dwa katalogi - convert i sources. Convert wrzuciłem, ale już sources nie, bo pomyślałem, że to jakieś dodatkowe pliki źródłowe. Wniosek: nie filozofować Ten drugi katalog jest cholernie ważny, bo w środku jest loginauth/convert. Razem z IPB też dostarczane są pliki tam znajdujące się, ale w starych wersjach i w efekcie: konwerter się nie wywala, ale NIE KONWERTUJE HASEŁ i przez to nie da się logować. Wpadłem na to przypadkowo chcąc sprawdzić, czy w auth.php jest prawidłowa wartość $itoa64, na co zwraca uwagę konwerter. Teraz czyszczę statystyki, zalogowałem się bez problemu. Modyfikacja musiała zostać - w połączeniu z ISO8859-2 daje mi to polskie znaki. EDIT: Po czyszczeniu statystyk: wygląda, że wszystko działa Dzięki @DawPi Mam jeszcze problem, dwie wątpliwości i jedno zapytanie: 1) Ze wszystkich postów wycięło emotikony. IPB tego nie konwertuje? Posty bez emot wyglądają niekiedy dość dziwacznie... Z tego co widzę w bazie w miejscu emot zostało: <!-- s:lol: --> (dla emoty "lol"). Da się to jakoś przetworzyć? Póki co mam pomysł, aby wykonać sprytne zapytanie na bazie, które w tabeli postów i sygnatur przerobi określony ciąg na inny (w tym przypadku to by było na : lol : (bez spacji), ale może da się to zrobić bez kombinacji tego typu podczas konwersji postów? 2) Przy konwersji wyświetlało mi różne liczby prywatnych wiadomości (po konwersji ich ilość w stosunku do phpBB się zwiększyła). Tak powinno być? 3) Po konwersji baza danych strasznie się upasła - ze 100 MB zrobiło się ponad 200 MB. W phpmyadmin wywaliło, że mam 6MB nieoptymalnych - no to zrobiłem optymalizację i... baza zmniejszyła się do jakichś 150 MB o_0. Tak się może dziać? 4) Pytanie: jak to teraz zgrabnie z localhosta przenieść na sieć. Po wrzuceniu bazy trzebaby coś pozmieniać - zapewne jakiś plik + jakieś wpisy w bazie wskazujące na instalację na localhost. Na co zwrócić uwagę? Jeszcze raz dzięki za dotychczasową pomoc. Meandry konwersji znaków w MySQL pozostaną dla mnie niezrozumiałe - mam UTF8, forum musi się łączyć przez latino2 i wyświetlać wszystko w ISO8859-2, ale unicode i tak działa - bez sensu, ale ważne, że śmiga.

Wygląda, że chyba poszło - widzę znaki w bazie = 50 procent sukcesu Niestety nie mogę się zalogować na stare dane. Nie mogę też zarejestrować nowego usera, bo pole wpisywania nazwy usera jest niedostępne... Na forum są krzaczki, ale z tym sobie już chyba poradzę - wydaje mi się, że ponowne wycięcie modyfikacji + ustawienie na utf-8 strony kodowej w ustawieniach forum powinno na to pomóc - wszak bazę mam w UTF-8 (a jak nie - to z tego drugiego tematu wynika, że trzebaby zmienić na iso-8859-2 bez ruszania modyfikacji w plikach). Proszę o pomoc w kwestii logowania na konto Admina, żeby przeczyścić statystyki - teraz nie mogę wejść w żaden temat. EDIT: Zapomniałem dodać - hasła też nie przywrócę - maile nie dochodzą, nie mam koncepcji jak się do tego dobrać teraz...

Jak patrzę po supportach IPB to problem z kodowaniem przy konwersji to już chyba standard Niestety trafił się i mi. Mam phpBB 3, które było updatowane z phpBB 2 kilka miesięcy temu. Uznałem, że czas zainwestować, bo forum się rozrosło i wybrałem IPB. Teraz mam problem z konwersją z phpBB 3. Baza phpBB 3 jest chyba w UTF-8 - tak się wyświetla w phpMyAdminie. Widzę polską czcionkę jak przeglądam pola. Tabele są podpisane jako utf8_bin i tak samo poustawiałem instalację IPB i metodę porównywania napisów. Niby ok. Uruchamiam konwerter. Tam nie ma nic o formacie znaków. Odpalam więc jak jest i po konwersji patrzę do bazy: zamiast polskich znaków tylko "?". Poczytałem po sieci i wiem już, że jeśli mam "?" w bazie to po zawodach - żeby chociaż krzaki były to byłby już postęp, bo to się da odkręcić, odpowiednio łącząc się z bazą... Jak wykonać konwersję, żeby uzyskać w bazie cokolwiek innego niż "?"? Co spróbować pozmieniać? Proszę o pomoc. PS: Wersja MySQL 5.0.45 jeśli to ma znaczenie, a php wersja to 5.2.5 - to gotowy pakiet WebServ zainstalowany lokalnie, bo na prawdziwym serwerze taka konwersja byłaby za trudna do wykonania. Bawiłem się też VertrigoServ, ale efekt ten sam. EDIT: Czy przed konwersją trzeba instalować spolszczenie? Może tu robię błąd (bo nie instaluję), ale jak piszę posty, to polskie znaki są, a nawet chińskie