Dyskusje na temat MyBB 2.0

Skrypt, skryptem, jednak kto tak naprawdę korzysta z samego skryptu podstawowego, bez dodatkowych templatek, czy pluginów? Z tym może być największy problem jeśli ktoś szybko będzie chciał migrować na nowa wersję.

Ja natomiast mam kilka pytań:
- Jak obecnie ze stabilnością tego forum? testował ktoś już?
- Czy będzie możliwość aktualizacji z linii 1.8.x, czy jedynie nowa instalacja wchodzi w grę? Może chociaż coś podobnego jak migracja z SMF do myBB?
- Czy planowane jest spolszczenie tej wersji, a jeśli to kiedy? czy po pokazaniu się oficjalnie stabilnej wersji zaczną się prace, czy wcześniej?

Obecnie jestem na etapie stawiania nowego form i tak się zastanawiam, czy aby od razu właśnie tej dwójki nie odpalić, aby się potem nie okazało, że migracja z linii 1.8.x nie będzie możliwa.

2.0 nie jest nawet w działającej fazie alpha, a Ty mówisz o rozważaniu jego instalacji? Fakt, że developerzy udostępnili kod, nie oznacza, że to, co jest tam dostępne, w ogóle działa.

Co do aktualizacji, to spokojnie. Na pewno dostaniemy narzędzie do migracji, gdy pojawi się wersja stabilna.

Jak dla mnie to:

• Wsparcie dla HTML5
  
• Wsparcie dla JQuery
  
• Standardowe templatki oparte na divah nie na tabelach!!! i wykorzystujące CSS3
  
• Wymuszenie na programistach pluginów, wsparcia dla innych silników baz danych, które wspiera MyBB, nie tylko MySQL (obecnie 99% pluginów działa niestety tylko z MySQl co jest według mnie karygodne)
  
• Lepsze wsparcie dla SEO (To że obecnie w standardowej instalacji MyBB nie można ustawić zdawało by się podstawowego metatagu description, jest jakimś koszmarem, ten tag powinien być inny dla każdej podstrony oczywiście.)
  

Jeśli mam być szczery, to elementy jakie wymieniłem nie są niczym nowym i ignorowanie tego jest strzałem w plecy. Jeśli MyBB ma być wykorzystywane w profesjonalnych zastosowaniach, a nie jako fora pasjonatów gier jak ma to miejsce obecnie w większości darmowych skryptów, MyBB musi zacząć wspierać nowe aktualnie wykorzystywane technologie, niestety. Także mieć pełne wsparcie dla Dla innych baz danych, nie tylko samego skryptu ale także i wtyczek. Wliczył bym tu w to także nie wspieraną obecnie bazę - Oracle. Zaczęcie wsparcia dla wyżej wymienionych elementów dopiero wtedy (czyli gdzieś w okolicach wersji 3 lub 4), jak biznes zacznie już od tego odchodzić, nie jest dobrym pomysłem według mnie jeśli ten skrypt ma się czymś konkretnym wyróżniać spośród konkurencji.

Jeśli skrypt ma się popularyzować musi mieć coś czego nie mają inni. Nie mówię tu o masie wodotrysków jak ma przemo ale pełnym wsparciu dla pluginów jak już pisałem, aby każdy mógł skorzystać z tych tylko co mu pasują i które wytrzyma mu serwer :] bez względu na to, czy ma podpięta bazę MySQL, czy PostgreSQl, czy może proponowaną bazę Oracle.

Jeśli mam być szczery, to pełne wsparcie dla takich baz jak PostgreSQl oraz Oracle spowodowało by rezygnację z IPB przez część for komercyjnych na rzecz MyBB właśnie, a jeśli dołączyć do tego resztę proponowanych przeze mnie elementów + skrypt migracyjny dla tych baz z IPB mogło by już na prawdę poważnie zagrozić IPB.

Na koniec podam, że jednym z ważniejszych dla mnie argumentów dlaczego ja wybrałem MyBB, a nie IPB dla forów, bylo wsparcie dla PostgreSQL właśnie. Nie przewidziałem tylko, że 99% pluginów nie wspiera tego silnika, a nie każdy plugin da się prosto przystosować do współpracy z ta bazą. Czasem jest to wielki problem niestety.


Tutaj jest takie fajne zestawienie Forów w Polsce oraz skryptów na jakich stoją i ich udział. MyBB nei wypada zbyt dobrze na tym tle, więc musi błysnąć czymś w nowej wersji czego nie mają inni, aby zdobyć większą popularność i przychylność internautów. http://blog.tiger.com.pl/2015/02/16/pols...nternecie/

Jak dla mnie to:

• Standardowe templatki oparte na divah nie na tabelach!!! i wykorzystujące CSS3
  

Proszę, powiedz, że żartujesz albo przynajmniej uogólniasz... Z jednej strony mówisz o HTML5, a z drugiej proponujesz chyba jedno z najgorszych semantycznie rozwiązań. Kontenery blokowe – tu jak najbardziej się zgodzę, ale zdecydowanie wolałbym, aby twórcy unikali DIVów wszędzie tam, gdzie będą mieli dostępne lepsze kontenery pod względem semantyki

Nie traktuj tych propozycji jako nierozerwalna całość. To nie błąd i nie żart. Jeśli HTML5 nie zostałby wdrożony jednak, to jak według ciebie miały by wyglądać standardowe szablony? w oparciu o <table> ? Osobiście nic nie mam do kontenerów, strony w oparciu o nie buduje się dość prosto i przyjemnie - szczególnie z wykorzystaniem css3, a i boty wyszukiwarek nie mają z nimi problemów. Mam bardzo wiele do zarzucenia za to szablonom budowanych o tabele. Tabele powinny być wykorzystywane do czego zostały stworzone, czyli danych tabelarycznych, a nie jako struktura stron.

Pomijając wyszukiwarki, weźmy chociażby responsywność szablonu. Jak bez wsparcia html5 chciałbyś taki template zrobić? w oparciu o co ? o tabele ?. Zakładając, że mam mieć on czysta i przejrzystą konstrukcję. Oczywiście można kombinować z przypisywaniem styli CSS do takich tagów jak <p>, <img .. >, <span> itp. ale chyba nie temu one służą i nie wydaje mi się, aby to był dobry pomysł. Uważam, że uzywanie kontenerów bez wsparcia dla html5 jest jedynym sensownym rozwiązaniem.

Nidraxowi chyba nie chodziło o budowanie strony na tabelach, tylko oto, żeby tam gdzie diva da się zastąpić lepszym znacznikiem, to to zrobić.
Na przykład zamiast <div id="footer"> to <footer>, w niektórych przypadkach <section> zamiast diva itp.

Nie traktuj tych propozycji jako nierozerwalna całość. To nie błąd i nie żart. Jeśli HTML5 nie zostałby wdrożony jednak, to jak według ciebie miały by wyglądać standardowe szablony? w oparciu o <table>?

JEŚLI nie wdrożyliby HTML5 (co byłoby z ich strony totalną głupotą, ale to tylko moje zdanie), to możnaby rozważyć te divy, chociaż nie jestem fanem zagnieżdżania diva w divie itd. Tym bardziej widząc, jak wygląda sprawa w aktualnych szablonach MyBB, boję się, że wynikiem byłaby straszliwa divitis vulgaris

Jak bez wsparcia html5 chciałbyś taki template zrobić? w oparciu o co ? o tabele ?

Zmiana wyświetlania tabeli na obiekt blokowy nie jest trudna, więc można bez problemu osiągnąć responsywność z tabelami (sam mimo posiadania template'a w dużej części zgodnej HTML5 mam to tak rozwiązane na forum, bo szybciej jest dodać kilka linijek kodu CSS niż edytować dziesiątki szablonów )

Nie ma się co dziwić, że na razie MyBB wypada tak, a nie inaczej na bardzo dużych forach (milion postów i więcej, sporo działów) - niektóre kwestie nie są przygotowane na taką skalę, co jednak wychodzi podczas używania. Z drugiej strony, taki ranking jest nieco sztywny. Zauważmy, że są tam głównie fora z baaardzo długą tradycją. No a jak coś nowego ma je przebić? Ot taka elektroda, przecież to stary silnik, ale tak zmodyfikowany, że bez ogromnych nakładów czasu nie do ruszenia.

A Elektroda to przypadkiem nie na PHPBB stoi?

Tak, dlatego właśnie o niej wspominam - to jeszcze phpBB 2, a więc wiekowy kod, który trudno zaktualizować przy takim forum.

Wsparcie dla JQuery

Przecież jQuery jest domyślnie używane już od 1.8.0... Nie wiem też co masz na myśli poprzez "wsparcie", bo jQuery można z łatwością dodać do dowolnego skryptu, nawet jeśli są konflikty z innymi bibliotekami JS.

Wymuszenie na programistach pluginów, wsparcia dla innych silników baz danych, które wspiera MyBB, nie tylko MySQL (obecnie 99% pluginów działa niestety tylko z MySQl co jest według mnie karygodne)

Ciekawe jak byś to wymusił. Przykładając programistom broń do czoła? Bo o ile można manualnie sprawdzać dodatki pod kątem jakości na głównym forum MyBB, jakoś nie jestem w stanie wyobrazić sobie robienia tego automatycznie podczas instalacji z innych źródeł. Tak czy tak słabej jakości kod zostanie częściowo wyeliminowany, gdyż deweloperzy kompletnie nieznający Laravela (w tym poprawnej obsługi baz danych) raczej nie będą w stanie stworzyć żadnej wtyczki.

Wliczył bym tu w to także nie wspieraną obecnie bazę - Oracle.

Laravel sam w sobie z tego co pamiętam wspiera "jedynie" MySQL/pgSQL/SQLite/MSSQL. Oczywiście istnieją odpowiednie rozszerzenia frameworka, ale jak na razie aż 0 osób na forum MyBB założyło temat sugerujący dodanie tego systemu baz danych.

Wsparcie dla HTML5

Standardowe templatki oparte na divah nie na tabelach!!! i wykorzystujące CSS3

Lepsze wsparcie dla SEO (To że obecnie w standardowej instalacji MyBB nie można ustawić zdawało by się podstawowego metatagu description, jest jakimś koszmarem, ten tag powinien być inny dla każdej podstrony oczywiście.)

To już dawno zostało potwierdzone, zresztą styl częściowo jest zaimplementowany i dostępny na Githubie, więc można z łatwością określić jego stopień wykorzystania nowych technologii.. Nie wiem jaki cel miał Twój post, ale wypadałoby zrobić jakiś research zanim się napisze coś tak długiego.

Ciekawe jak byś to wymusił.

Tu się akurat da i to się zresztą stanie - deweloper nie będzie przecież sam korzystał z biblioteki mysqli czy PDO, ale właśnie warstwy abstrakcyjnej, którą dostarczy framework lub tym bardziej MyBB. Nie musi wiedzieć, co jest pod spodem, nie musi wiedziec, jakie bazy obsługuje, a po prostu używa. Oczywiście ma to i ograniczenia, takiego full-uniwersalnego systemu to nie ma.

Już teraz "jest", tyle tylko, że interfejs DB_Base i implementujące go klasy nie są tak ściśle określone, aby przy np. tworzeniu nowych tabel nie można było wykorzystywać opcji specyficznych dla danego typu bazy. Da się, co zresztą czasami prowadzi do problemów - ot spróbujmy sobie w instalatorze pluginu dodać FULLTEXT na tabelce InnoDB przy MySQL niższym niż 5.6

Nie ma na to szans z prostego powodu - różnice w implementacji i oferowanych funkcjach sprawiają że zwyczajnie nie da się zoptymalizować bazy danych pod wiele silników, więc na koniec dnia 99% kodu będzie zakładać że baza danych to MySQL i kwiczeć na np. SQL-Serverze a ten 1% Postgresowców nie będzie się przejmować resztą i będzie sobie robić indeksy dynamiczne na hstorach w surowym SQL'u.

Ciekawostka: w PostgreSQL coś takiego jak FULLTEXT zwyczajnie nie istnieje. Zamiast tego należy stworzyć indeks (jest kilka typów funkcji indeksujących różniących się mechanizmem analizowania danych) z wybranej funkcji (jest kilka funkcji do przekładania tekstu na rozmaite struktury danych). Wyniki działania tych funkcji można zapisywać w tabeli jako pseudokolumny dla przyśpieszenia operacji przeszukiwania. Teraz już można przeszukiwać tekst budując odpowiednie zapytania... do czego ofc służą dedykowane funkcje które przeszukują tekst pod różnym kontem w zależności od funkcji i treści zapytania. Dajcie mi ORM który to ogarnie.

Nie damy - dlatego właśnie tworzenie dodatkowych warstw abstrakcji jest wygodne (bo szybciej), ale i uderza w możliwość pełnego wykorzystania danego oprogramowania (albo ogólnie mówiąc całej infrastruktury).