[quote=hubertlepicki]Trzeba by obadać jak to forum jest indeksowane przez google. W tej chwili jest bardzo dobrze pod tym względem i często, gdy wpiszesz jakiś problem w Google wyskakuje właśnie forum.rubyonrails.pl.
Bardzo podoba mi się tamto rozwiązanie na pierwszy rzut oka, ale jeśli się okaże że Google nie potrafi tego wogóle zaindeksować, albo indeksuje źle/niepełnie, ja bym się wycofał z tego pomysłu.[/quote]
Najpierw walczymy z SEO spamem, a potem chcemy być SEO friendly
Ogólnie plan migracji jest narazie taki:
Nowa instancja forum bez danych na rubyonrails.pl/forum2/
Projekt migratora danych punbb -> discourse na github
Migracja SEO jeśli będzie możliwa po kompletnym zmigrowaniu danych
Jeśli nie będzie żadnych krytycznych przeciwskazań przerzucamy forum2 -> forum
To bym dał jako warunek konieczny przerzucenia na nowy silnik. Osobiście nienawidzę jak wyguglane linki robią 404 bo właściciel znów w danym miesiącu zmienił silnik blogaska i nie chciało mu się ustawić redirectów.
Tylko teraz pytanie - poklikamy, poklikamy i co? Nie wiem co musiało by się zdarzyć, żebym nie chciał tego forum, ale zakładasz, że nie wiem - będzie głosowanie?
[quote=Paweł Kondzior]Ogólnie plan migracji jest narazie taki:
Nowa instancja forum bez danych na rubyonrails.pl/forum2/
Projekt migratora danych punbb -> discourse na github
Migracja SEO jeśli będzie możliwa po kompletnym zmigrowaniu danych
Jeśli nie będzie żadnych krytycznych przeciwskazań przerzucamy forum2 -> forum[/quote]
Lepiej discourse.rubyonrails.pl - mogę wtedy ustawić subdomenę na CNAME costam.shellycloud.com jeśli wersja “demo” ma tam stać
Przydałyby się osoby chętne do pracy nad migratorem ( założenie projektu na GH i prowadzenie). Co do punbb to proponuję pobrać najnowszą wersję punBB i pracować nad tym. Z tego co pamiętam nie zmienialiśmy schematu bazy więc ogólnie nie powinno być problemów z jakimiś dziwnymi rozszerzeniami. Na obecnym forum jest syntax highlighter, prosty anty spam field i friendly urls z tego co pamiętam.
Jest do zrobienia. Dobrze byłoby gdyby migrator generował .htaccess z regułkami lub tworzył automatycznie mapę stary_url -> nowy_url którą później możnaby podpiąć pod serwer.
Ogólnie discourse wygląda OK, brakuje mu póki sporej ilości ficzerów znanych z pehapowych silników ale nie mamy dużych wymagań (może poza wyodrębnianiem wątków). Nie przyglądałem się wcale jak wygląda sprawa uprawnień (moderatorzy, grupy etc.) ani możliwości rozszerzeń. (czy jest jakieś API czy alias_method_chain i jedziemy)
Jeśli chodzi o migrację z punBB, macie mój topór. Nie znam silnika, ale trochę już danych migrowałem, a i chciałbym też przygotować migrację z phpbb3 na Discuss.
Nie licząc strony głównej, to niestety ciężko poklikać po aplikacji, bo w tym momencie nie obsługujemy dwóch gemów - sidekiq i clockwork (póki co mamy odpowiednio delayed_job i whenever).
Nie wyklucza to jednak tego, że chcemy dodać dla nich wsparcie, teraz tylko potrzebna jest decyzja administratorów forum czy wybierają hosting na Shelly Cloud. Jeżeli tak to przenosimy implementacje wsparcia dla sidekiqa i clockworka na bieżący sprint, żeby było to gotowe jak najszybciej.
Z naszej strony możemy zaoferować obsługę taką samą jak dla płacących klientów czyli: odpowiednia liczba instancji, żeby wszystko płynnie działało, pełne wsparcie na supporcie i wszystkie dodatkowe usługi, które oferujemy bądź będziemy oferować.
Dajcie znać czy Wam to odpowiada, jeżeli tak to poproszę o mail na bkzl@shellycloud.com komu mam dać dostęp do deploymentu przez Shelly.
Moim zdaniem kod powinien być otwarty, tak żeby każdy mógł wrzucić swoje zmiany w pull requeście. Te ustawienia nie wyglądają na takie, które muszą być prywatne, a jeżeli nawet część z nich będzie, to jest dużo sposobów na trzymanie tego poza repozytorium.
Moim zdaniem kod powinien być otwarty, tak żeby każdy mógł wrzucić swoje zmiany w pull requeście. Te ustawienia nie wyglądają na takie, które muszą być prywatne, a jeżeli nawet część z nich będzie, to jest dużo sposobów na trzymanie tego poza repozytorium.[/quote]
+1 rails way
Shelly ma osobny git remote. Jest wykorzystywany tylko do deploy - i w nim umieszcza się zmiany w plikach niezbędne dla konkretnego deploymentu.
Możemy spokojnie publikować całość kodu na githubie jak długo sekrety będą tylko w repo Shelly, widoczne tylko dla administratorów projektu.
Dodatkowo, jeśli obawiacie się wycieku sekretów na skutek błędnego merge, Shelly oferuje osobny skład dla tego rodzaju plików. Uploaduje się je osobno podczas deploymentu Shelly nadpisuje nimi te, które są w repo. Double security dla mniej uważnych
W travisie config jest ustawiany na heorku właśnie poprzez ENV variables w postaci przesłanego tam YAMLa. Oddzielny remote brzmi o tyle kiepsko, że trzeba by to merge’ować cały czas zamiast po prostu robić push mastera.
W travisie config jest ustawiany na heorku właśnie poprzez ENV variables w postaci przesłanego tam YAMLa. Oddzielny remote brzmi o tyle kiepsko, że trzeba by to merge’ować cały czas zamiast po prostu robić push mastera.[/quote]
U nas wygląda to trochę inaczej, zamiast ENV vars do trzymania ustawień poza repozytorium można skorzystać np. z gema rails_config (https://github.com/railsjedi/rails_config) a następnie uploadować i edytować plik z konfiguracją z konsoli poleceniem shelly config - https://shellycloud.com/documentation/configuration_files
Jeżeli chodzi o osobny remote dla Shelly, to jest on używany tylko jako kopia głównego repozytorium służąca do deploymentu. Pomimo tego co napisał Bragi nie polecamy trzymania osobnych plików w remocie Shelly (i chyba nikt u nas tego nie praktykuje), tylko właśnie skorzystania z wspomnianego shelly config, wtedy repozytorium główne i Shelly nie różnią się i nie wymagają mergów, a deploy mastera ogranicza się do git push production master.
Jeszcze wracając do mojego:
To znowu trochę pospieszyłem się z odpowiedzią, za co Was przepraszam, bo oczywiście nic nie stoi na przeszkodzie, żeby wyciągnąć newralgiczne dane poza repo.
