Specyfikacja techniczna Culture.pl

Transkrypt

1 Specyfikacja techniczna Culture.pl 1/20

2 Dokumentacja Wyszukiwarka Wydajność wyszukiwarki Wydajność Aplikacji Frontend Backend Testy wydajności SEO Analityka Okresowe zadania konserwacyjne dla systemu Obsługa błędów Migracja treści z serwisów powiązanych IAM Migracja serwisu eepap.org Dodatkowy poziom uprawnień użytkowników Edytowalne dokumenty Migracja danych Eksport artykułów dot. Polski Osobna instancja Migracja serwisu IAM.pl Migracja treści Culture.pl Integracja z Social Media Implementacja AdSerwera Bezpieczeństwo Gwarancja Wersja mobilna Wersja dla niepełnosprawnych Wersja żałobna serwisu Multisite Wielojęzykowość Projekty lokalne i submarki Różnice layoutowe między submarkami System oceny pracy autorów Szczegółowy opis: Uprawnienia związane z rozliczaniem czasu pracy Statystyki przyrostu treści Panel administracyjny Przepływ zadań/schemat publikacji Właściwości systemu CMS 2/20

3 Dokumentacja Wykonawca powinien przedstawić szczegółową dokumentację wykonanej aplikacji. Dokumentacja powinna się składać z: 1. Specyfikacji Funkcjonalnej opisującej sposób wdrożenia danych rozwiązań określonych przez Zamawiającego 2. Specyfikacji Technicznej składającej się z: a. szczegółowego opisu wymagań technicznych aplikacji zawierającej informacje o wszelkich, wymaganych przez aplikację usługach, programach i bibliotekach, wraz z ich wersjami (PHP 5.3, java, biblioteki do konwersji grafiki, biblioteki kryptograficzne, rozszerzenia PHP etc.) b. szczegółowej, wygenerowanej automatycznie z kodu źródłowego aplikacji, dokumentacji w postaci dokumentu elektronicznego Wykonawca ma obowiązek aktualizować dokumentację podczas wprowadzania zmian, bądź poprawek w systemie, także po wykonaniu zlecenia, w okresie trwania gwarancji. Wykonawca powinien prowadzić dokumentację zmian w repozytorium wykorzystanym podczas tworzenia aplikacji. Zamawiający powinien mieć pełen dostęp co najmniej do gałęzi produkcyjnej aplikacji w repozytorium, z możliwością podejrzenia zmian oraz komentarzy dotyczących tych zmian. Wyszukiwarka Wyszukiwarka powinna zostać wdrożona z wykorzystaniem usługi Apache Solr w wersji co najmniej 3.5. Wyszukiwarka powinna indeksować treści w sposób przyrostowy - bez konieczności zatrzymywania aplikacji na czas reindeksacji treści. Dokładna lista indeksowanych pól zostanie dostarczona wykonawcy w ramach specyfikacji serwisu. Wykonawca powinien zakładać, że wyszukiwarka pozwala wyszukiwać po wszystkich polach dostępnych dla danego typu treści. Wyszukiwarka powinna wykorzystywać możliwość grupowania wyników (faceting). Wyszukiwarka powinna mieć zaimplementowane zaawansowane rozwiązania, takie jak stemming, listy synonimów, listy słów zakazanych (badwords). Wyszukiwarka powinna obsługiwać mechanizm automatycznego podpowiadania w polu wyszukiwania serwisu (autocomplete), wyświetlającego wyniki na podstawie ustalonych przez Zleceniodawcę reguł. 3/20

4 Wyszukiwarka powinna integrować się z systemem w taki sposób, aby możliwe było za jej pomocą ładowanie treści do bloków typu podobne artykuły, ostatnie artykuły, tego dnia wydarzyło się itp. Wyszukiwarka powinna umożliwiać konfigurację zaawansowanego algorytmu sortowania wyników na podstawie wag przypisywanych do każdego pola zdefiniowanego dla treści serwisu. Wyszukiwarka powinna umożliwiać zmianę algorytmu ważenia w zależności od miejsca w którym wyświetlamy wyniki - inne wagi przypisujemy polom na ekranie wyników wyszukiwania, inne w blokach typu ostatnie treści, podobne artykuły etc. Wyszukiwarka powinna umożliwiać automatyczne podświetlanie wyszukiwanych fraz, bądź ich synonimów na ekranie wyników wyszukiwania, oraz wycinanie fragmentów artykułów, tak aby zajawka artykułu zawierała szukane frazy. Wydajność wyszukiwarki Wyszukiwarka powinna wykorzystywać mechanizmy cache, tak aby powtórne zapytanie zwracało odpowiedź w czasie mniejszym niż 200ms. Cache powinien być aktualizowany tylko w przypadku pojawienia się nowych danych w indeksie wyszukiwarki, które zmieniałyby wyniki wyszukiwania. Wyszukiwarka powinna być skonfigurowana w taki sposób, aby czas wyszukiwania dla obecnej bazy treści culture.pl (40000 artykułów) był liniowy i nie przekraczał 1000ms. Serwer wyszukiwarki, powinien poprawnie wysyłać znaczniki E-Tag/Expires, tak, aby przeglądarka mogła kontrolować cache po swojej stronie i nie pobierać niepotrzebnie zawrtości, która nie uległa zmianie. Wydajność Aplikacji Serwis, z racji tego, że odbiorcy będą anonimowymi użytkownikami, a komentarze zostaną wdrożone poprzez zewnętrzne mechanizmy typu FacebookComments, powinien bardzo agresywnie używać mechanizmów cache. Cache powinien być wykorzystany na każdym poziomie obsługi żądania http, tak aby uniknąć przetwarzania requestu po stronie aplikacji. Mechanizmy, które powinny być wdrożone: integracja z reverse proxy (Varnish) zgodnie z RFC2616 wykorzystanie mechanizmów cache dla zapytań do bazy (memcache) cache powtarzalnych elementów strony, takich jak bloki polecane (memcache) 4/20

5 cache dla całych, wygenerowanych stron (static/memcache) najlepsze praktyki w kodzie dot. sposobu wykorzystania zmiennych, ograniczania liczby zapytań do bazy danych, generowania obiektów CMS powinien umożliwiać z poziomu panelu administracyjnego, wyczyszczenie każdego poziomu cache, na wypadek zaistnienia takiej potrzeby. W momencie aktualizacji danego artykułu, cache widoków dla których wyświetla się artykuł powinien być czyszczony - aplikacja powinna czyścić także widok strony głównej lub kategorii, jeśli na tych stronach pokazuje się zajawka artykułu. Frontend Skórka serwisu powinna zostać wykonana zgodnie z aktualnymi najlepszymi praktykami dotyczącymi wydajności aplikacji pod kątem czasu ładowania się strony. W szczególności: wszelkie grafiki wykorzystywane jako elementy interfejsu, powinny być połączone w jeden sprite ikony lub inne znaki graficzne powinny być połączone w plik czcionki (woff, ttf) i serwowane jako jeden zasób małe obrazki, będące elementami interfejsu, powinny być zaszyte w plikach css w postaci ciągu data:image base64 wszelkie zasoby statyczne, będące częścią interfejsu graficznego (css,js, ikony, czcionki, obrazki interfejsu) powinny być serwowane z osobnej subdomeny s.culture.pl obrazki niebędące elementami interfejsu powinny być ładowane z wykorzystaniem mechanizmu lazy load - co oznacza ich załadowanie dopiero w momencie, gdy użytkownik przewinie stronę w przeglądarce do miejsca w którym powinna się wyświetlić dana grafika. mechanizm lazyload powinien działać także dla elementów poziomych, takich jak karuzela, która standardowo nie podpada pod mechanizmy lazyload, ponieważ mechanizm uznaje, że wszystkie występujące w jej obrębie grafiki, znajdują się w polu widzenia użytkownika - pomiar na podstawie osi pionowej. pliki javascript i css powinny być łączone w jeden plik i kompresowane biblioteki javascript, takie jak jquery, powinny być pobierane z adresów CDN Google/Microsoft - jako jedyne są wyłączone z obowiązku łączenia i kompresji Ze względu na RFC2616, to aplikacja steruje nagłówkami expires, w związku z czym, obrazki oraz inne elementy statyczne, powinny mieć ustawiony maksymalny czas przedawniania strony powinny wysyłać nagłówki ETag aby umożliwić weryfikację, czy wersja leżąca w cache przeglądarki jest aktualną wersją strony wszelkie skrypty powinny być ładowane asynchronicznie, a układ strony i podstawowe definicje elementów powinny zapobiegać skakaniu layoutu jeśli któryś ze skryptów zmienia jego wygląd/położenie elementów 5/20

6 reguły CSS oraz modyfikacje w drzewie DOM wykonywane poprzez skrypty javascript, powinny powodować minimalną liczbę zdarzeń typu reflow w przeglądarce strona może wykorzystywać framework css strona powinna zawierać minimalną ilość kodu html, tak aby proporcja treści strony do kodu wyświetlającego tą treść była jak największa szczególną uwagę należy tutaj zwrócić na generowanie nadmiarowych klas i identyfikatorów, oraz wielokrotnie zagnieżdżonych znaczników, przez system CMS obrazki wysyłane przez serwer nie powinny być kompresowane przez serwer (gzip) a jedynie optymalizowane przez aplikację w momencie generowania miniatur. Backend Czas odpowiedzi strony html (mediana) nie powinien przekraczać 2000ms przy zimnym cache, 600ms przy wykorzystaniu cache aplikacji i 250ms przy wykorzystaniu Varnish cache. Powyższe czasy zakładają, że na stronie znajduje się jednocześnie 500 użytkowników oraz wykonywane jest 50 odsłon stron na sekunde. Odsłona oznacza tutaj pobranie strony wraz z wszystkimi zasobami wymaganymi do jej wyświetlenia. Layout strony powinien generować maksymalnie następującą liczbę zapytań do serwera (dla niezalogowanego użytkownika): pliki html: 1 pliki css: 1 pliki javascript: 1 pliki graficzne: 4 pliki czcionek: 2 zapytania do adserwera: 2 Powyższe ograniczenia nie dotyczą plików graficznych występujących w zajawkach artykułów, ale z nimi związany jest temat lazy-load więc nie powinny znacząco powiększać liczby zapytań i doczytywać się podczas przewijania strony. Zapytania wysyłane do zewnętrznych serwerów nie są wliczane, ale także powinny być bardzo ograniczone, tak aby sumaryczna liczba zapytań wymaganych do załadowania strony nie przekraczała 30. Funkcje takie jak ocenianie artykułów, powinny być zaimplementowane za pomocą mechanizmów Ajax. Samo wyświetlanie powinno być wbudowane w stronę, ale aktualizacja oceny po zagłosowaniu powinna być wysyłana do serwera za pomocą żądania javascript. Testy wydajności Wykonawca powinien dostarczyć wraz z projektem, wyniki badania wydajności aplikacji za pomocą narzędzia klasy ab/siege/jmeter. 6/20

7 Raport powinien zawierać: dokładne informacje o konfiguracji sprzętowej serwera, na którym była testowana aplikacja, konfiguracji poszczególnych usług (serwer www, baza danych, memcache, solr), dokładnej konfiguracji narzędzia, którym wykonywano pomiar ile wątków wykorzystywało narzędzie jaka była przepustowość łącza między serwerem testowym a serwerm z aplikacją testującą informacje o wynikach testu dla aplikacji w stanach wyłączony cache włączony cache rozgrzany cache zimny cache szacunki dotyczące ograniczeń aplikacji i poziomu ruchu jaki jest w stanie obsłużyć przy wykorzystaniu proponowanej konfiguracji sprzętowej zmiany, które zostały wprowadzone w konfiguracji usług po testach wydajnościowych Testy wydajności powinny zawierać informacje zarówno o średnim czasie odpowiedzi i pobierania strony, jak i inne statystycznie istotne miary, takie jak mediana czy odchylenie standardowe dla żądań. SEO Serwis powinien być zbudowany zgodnie z aktualnymi najlepszymi praktykami SEO, zaczynając od tak podstawowych spraw, jak przyjazne adresy url, prawidłowe wykorzystanie tagów html na stronie, poprzez pełną implementację mikroformatów, optymalizacji obrazków poprzez automatyczne generowanie ich nazw i wypełnianie pól alt/title, aż po automatyczne mechanizmy pozwalające na szybką indeksację serwisu przez crawlery. Serwis powinien automatycznie tworzyć sitemapy XML (artykuły oraz grafiki), oraz zgłaszać je po wygenerowaniu do Google. Serwis powinien zawierać mechanizmy, które automatycznie będą tworzyły linki dla określonego zestawu fraz, kierujące do innych podstron serwisu, bądź poza serwis. Powyższy mechanizm powinien przewidywać limity liczby linków w pojedynczym artykule. CMS powienien umożliwiać ręczne nadpisanie adresu url danej strony, automatycznie obsługując przekierowania z wszystkich poprzednich adresów za pomocą przekierowania 301. CMS w ramach obsługi przyjaznych adresów, nie powinien pozwalać na indeksowanie stron w ścieżkach systemowych, takich jak /taxonomy/term/1, lecz automatycznie przekierowywać z nich na prawidłowy, przyjazny adres, który będzie indeksowany. 7/20

8 Wdrożenie powinno zagwarantować 100% przekierowań z poprzednich adresów, pod którymi występowały artykuły na nowe adresy w obrębie nowego systemu. Przekierowania te dotyczą także stron innych niż culture.pl, które także będą migrowane w obręb serwisu. W przypadku, gdy artykuł jest pisany w języku innym niż angielski lub polski, adresy URL artykułów (slugi), powinny być tworzone na podstawie dodatkowego pola, w które autor wpisu wprowadzi tytuł artykułu po angielsku. System nie powinien tego procesu automatyzować, a pole powinno być obowiązkowe. Analityka Strona powinna implementować zbieranie danych za pomocą mechanizmu Google Analytics, zgodnie z instrukcją dostarczoną w ramach specyfikacji strony. Wykonawca powinien zakładać wdrożenie zaawansowanej analityki, w tym wykorzystania mechanizmów takich jak śledzenie zdarzeń, zmienne niestandardowe, ecommerce, wirtualne odsłony, zliczanie danych do wielu profili, przekazywanie zmiennych js na potrzeby Tag Managera, oraz różne inne, dowolne modyfikacje kodu Google Analytics. Aplikacja powinna przekazywać do kodu strony, zdefiniowane w specyfikacji zmienne, zawierające przykładowo typ wyświetlanej strony, jej autora bądź kategorię w której dany wpis został opublikowany, tak, aby można je było następnie wykorzystać podczas wdrażania zliczania statystyk. Okresowe zadania konserwacyjne dla systemu System CMS powienien posiadać automatyczne zadania konserwujące, odpalane za pomocą mechanizmu CRON. Mechanizm ten powinien działać niezależnie od ruchu na stronie - to znaczy, że nie może być wywoływany w momencie wejścia użytkownika na stronę, lecz za pomocą wewnętrznego dziennika zadań systemu. Mechanizmy te powinny dbać o odświeżanie wszelkiego typu indeksów, cache, logów itp. mechanizmów które mogą sprawić, że aplikacja będzie działała wolniej niż zakładane w SLA parametry. System powinien automatycznie sprawdzać dostępność aktualizacji i informować o wszelkich znanych zagrożeniach, zarówno administratora aplikacji po stronie IAM, ajk i osobę odpowiedzialną po stronie wykonawcy. Obsługa błędów Wszelkie błędy, zarówno te leżące po stronie aplikacji (404 etc.) jak i te leżące po stronie serwera (500, 503), powinny mieć przygotowane osobne layouty, prezentujące użytkownikowi informacje o problemie. Strony te powinny także mieć wdrożone śledzenie w GoogleAnalytics aby umożliwić centralne zbieranie informacji o błędach. 8/20

9 Aplikacja powinna zapisywać informacje o błędach aby umożliwić identyfikację ich przyczyn i ułatwić zapobieganie ich kolejnym wystąpieniom. Aplikacja powinna przechowywać informacje o 5000 ostatnich błędów (system powinien automatycznie odcinać starsze dane). Migracja treści z serwisów powiązanych IAM W obręb serwisu Culture.pl zostaną zmigrowane następujące serwisy, należące do Instytutu Adama Mickiewicza: azja.iam.pl kidsculture.pl klopsztanga.de przewodnikdopolakow.pl (wraz z satelitami) eepap.org iam.pl wszystkie serwisy z subdomen culture.pl lutoslawski.culture.pl dadada.culture.pl pozostałe pomniejsze serwisy W drodze dalszych ustaleń z wykonawcą zostaną podjęte decyzje, czy dany serwis będzie migrowany automatycznie, czy też w ramach migracji treści zostaną przeniesione ręcznie do nowego systemu. Migracja serwisu eepap.org W skład migracji wchodzi serwis eepap.org, który rozszerza funkcjonalność docelowego systemu o następujące elementy: Dodatkowy poziom uprawnień użytkowników Poza użytkownikiem anonimowym (czytelnikiem), który ma dostęp jedynie do frontendu serwisu, oraz użytkownikiem należącym do redakcji (administrator, moderator, dziennikarz), pojawia się nowa rola użytkownika, który będzie mógł się zarejestrować w systemie, wypełniając specjalnie do tego celu przygotowany formularz. Wypełnienie formularza rejestracyjnego tworzy w systemie użytkownika, który nie jest aktywny - nie może się zalogować. Użytkownik musi potwierdzić podany w formularzu mail, poprzez kliknięcie w link aktywacyjny w przesłanej na jego adres wiadomości. Po potwierdzeniu adresu , użytkownicy typu moderator, mają możliwość aktywowania konta takiego użytkownika. 9/20

10 Serwis eepap.org ma za zadanie umożliwiać przedstawicielom instytucji kulturalnych, bądź pojedynczym artystom, publikację swoich artykułów w serwisie. Użytkownik taki powinien mieć także profil, w którym może dokładnie opisać instytucje, której jest przedstawicielem, bądź swoją osobę. Artykuły pisane przez takiego użytkownika, są automatycznie publikowane w systemie, ale nie ma on możliwości promowania tych treści poprzez dostępne w systemie mechanizmy promocji, typu: promuj na stronie głównej/stronie kategorii dodaj do slidera/karuzeli Możliwość promowania takich wpisów mają jedynie użytkownicy należący do redakcji. Wpisy opublikowane przez takiego użytkownika, wyświetlają się jedynie na stronie danej instytucji/artysty, jako stream wpisów, oraz w widoku pojedynczego wpisu. W mechanizmach typu podobne treści, gdzie wyboru dokonuje automat, wpisy danego autora mogą się pokazywać - nie wymaga to specjalnego ustawienia we wpisie. Oczywiście jeśli dany boks wymaga konkretnego atrybutu wpisu, przykładowo polecane wpisy, treść tego typu znajdzie się w nim tylko w wypadku, gdy redakcja włączy daną cechę we wpisie. Edytowalne dokumenty Zarejestrowani użytkownicy typu artysta/instytucja, powinni mieć możliwość edycji artykułów należących do konkretnego typu treści. Projekt zakłada, że będą oni współtworzyć strony zbierające informacje o danym artyście czy instytucji. W związku z powyższym, system powinien przechowywać kompletną historię wersji danego wpisu. Migracja danych Projekt zakłada pełną migrację danych z tego systemu. System jest obecnie zbudowany, tak samo jak culture.pl, przy użyciu systemu Liferay, co sprawia, że struktura danych do migracji będzie bardzo podobna, jeśli nie identyczna. Eksport artykułów dot. Polski Mała część artykułów publikowanych w systemie eepap.org, będzie dotyczyła Polski. W związku z tym, system powinien umożliwiać automatyczne przedrukowanie takiego artykułu w domenie culture.pl. Przedruk ten, będzie musiał wskazywać za pomocą tag a canonical na oryginalny artykuł w serwsie eepap.org. Przedruk początkowo nie powinien być automatycznie publikowany - powinien trafiać do kolejki moderatora jako nieopublikowany. 10/20

11 Dopiero po ręcznym zatwierdzeniu przez moderatora, artykuł tego typu, powinien być publikowany. System przedruków powinien przewidywać możliwość zmiany zasady działania tej funkcji tak, aby artykuły były publikowane automatycznie. Nie jest w tym miejscu wymagany podział na mniej lub bardziej zaufanych redaktorów, których wpisy będą się publikować, lecz globalny przełącznik, który pozwoli zmienić tą logikę. Osobna instancja Serwis eepap.ogr powinien stać a osobnej instancji systemu dostarczonego przez Wykonawcę. Migracja serwisu IAM.pl Serwis jest serwisem stanowiącym wizytówkę instytutu, a jego rolą jest przekazywanie informacji o aktualnych wydarzeniach którym patronuje instytut, oraz ułatwianie osobom zainteresowanym wspłpracy z instytutem. Strona ta, pomimo że będzie korzystała z wielu funkcji tworzonych na potrzeby serwisu culture.pl, będzie od niej odrębna layoutowo. Zamawiający dostarczy dla tego serwisu osobny projekt skórki, który pozwoli realizować cel wyznaczony dla strony. Najważniejsze cechy serwisu: 1. Kontakty - osoby szukające możliwości skontaktowania się z pracowanikami, bądź współpracownikami instytutu, powinni mieć dostęp do rozbudowanych profili tych osób a. wydarzenia opisywane w serwisie powiny być łączone z konkretnymi osobami, które brały udział w organizacji danego wydarzenia 2. Strony wydarzeń/instytucji - tutaj, podobnie jak w przypadku eepap.org, mamy doczynienia ze stronami zawierającymi dokładne informacje o danym wydarzeniu/artyście/instytucji 3. Zaawansowany formularz do składania podania o dotację - wielokrokowy formularz, pozwalający na załączanie plików (grafiki, dokumnety), z wbudowaną walidacją i owym potwierdzaniem wysłania formularza 4. Automatyczny BIP 5. Możliwość rejestracji użytkowników (Artyści/Instytucje/Dziennikarze) 6. Możliwość pobierania przez zarejestrowanych użytkowników materiałów źródłowych, takich jak zdjęcia w wysokiej rozdzielczości a. ta opcja będzie wymagała zaakceptowania specjalnego regulaminu związanego z udostępnianiem i wykorzystywaniem materiałów Migracja treści Culture.pl System, z racji istnienia poprzedniej wersji strony, zostanie zasilony treściami wyeksportowanymi z poprzedniej wersji w postaci plików XML. Do plików zostanie dostarczony plik DTD zawierający definicje typów i pól zawartych w eksporcie. 11/20

12 Proces importu powinien zakładać pewne automatyczne operacje, umożliwiające wprowadzanie masowych poprawek w migrowanych treściach. Operacje te, będą miały na celu oczyszczenie danych, przykładowo połączone zostaną tagi, które oznaczają to samo, lecz są inaczej pisane. Migracja treści powinna też umożliwiać wprowadzanie nowych, nieistniejących wcześniej zależności między treściami - mogą zostać wytworzone taksonomie na podstawie analizy zawartości danych pól. Może też nastąpić normalizacja i denormalizacja danych. Integracja z Social Media Serwis powinien integrować się z obecnie najpopularniejszymi serwisami społecznościowymi, takimi jak Twitter, Facebook czy Pinterest. Dokładny poziom integracji zostanie określony w specyfikacji serwisu. Wykonawca powinien zakładać, że jest to ponadstandardowy poziom integracji, wykorzystujący przykładowo automatyczne wstawianie danych opengraph na potrzeby serwisu Facebook, automatyczne skracanie adresów url przy wysyłaniu informacji na serwis Twitter, możliwość automatycznego eksportu galerii do serwisu Pinterest, możliwość wykorzystania mechanizmu social reading serwisu Facebook, możliwość wykorzystania mechanizmu komentarzy Facebook dołączanych do wpisu, wraz z wyświetlaniem w treści strony kopii tych komentarzy, tak aby były one indeksowane przez roboty wyszukiwarek. Implementacja AdSerwera Strona internetowa Culture.pl serwuje reklamy za pośrednictwem lokalnej instancji serwera reklam OpenX. Rozkład stref reklamowych zostanie załączony do szczegółowej specyfikacji technicznej, która będzie udostępniona wykonawcy po rozpoczęciu wykonywania zlecenia. Wykonawca jest zobowiązany dostarczyć wszelkie dodatkowe skrypty (javascript) wymagane do wyświetlania zaplanowanych form reklamowych, które wymagają dodatkowych skryptów - przykładem może tu być toplayer oraz expand/rollover. Wykonawca jest zobowiązany zaimplementować kody OpenX tak, aby zawartość wszystkich stref była pobierana za pomocą jednego zapytania do adserwera - zgodnie z opisem na stronie W obecnej chwili, specyfikacja serwisu przewiduje jedynie następujące formy reklam: billboard (750x100/200/300), tapeta (1280x800), halfpage (300x600). Te założenia mogą ulec zmianie, ale mało prawdopodobne wydaje się wykorzystanie bardziej agresywnych form typu toplayer. Bezpieczeństwo System powinien szyfrować hasła użytkowników za pomocą bcrypt, z unikalną solą dla każdego użytkownika. Hasło, zarówno w formie plaintext jak i zahashowanej, nie powinno się znaleźć w żadnym typie pamięci cache. 12/20

13 Kopia deweloperska serwisu powinna anonimizować bazę poprzez nadpisywanie losowymi wartościami wszelkich danych osobowych w niej zawartych. Powinna też nadpisywać hasła użytkowników tak aby jej wykradzenie nie pozwalało na uzyskanie dostępu do wersji live serwisu. Serwis powinien umożliwiać logowanie się użytkownikom tylko z określonych zakresów adresów IP. Wszelkie dodatkowe usługi wykorzystywane przez aplikacje, powinny być dokładnie opisane, wraz z informacjami w jaki sposób aplikacja się z nimi komunikuje. przykładem może być tutaj usługa memcache, która powinna komunikować się na porcie i ograniczać możliwość łączenia się z nią tylko do adresu IP serwera na którym stoi aplikacja. Inne, przykładowe usługi: Varnish, Solr, redis, aplikacja skracająca adresy URL. Wszelkie pola formularzy powinny podlegać walidacji zarówno po stronie przeglądarki użytkownika, jak i po stronie systemu. Zapytania do baz danych powinny być zabezpieczone przed atakami typu SQL injection, w szczególności powinny używać parametrów. Mechanizmy obsługujące ładowanie do serwisu zdjęć, powinny być zabezpieczone przed atakami LFI i innymi, które można wykonać z pomocą tego typu mechanizmów. Pliki cookie powinny być zabezpieczone przed dostępem z poziomu skryptów javascript poprzez ustawienie flag HTTP only. Wykonawca, w ramach zlecenia przeprowadzi testy bezpieczeństwa aplikacji za pomocą narzędzia klasy skipfish, rozwiąże wszelkie znalezione problemy i usunie luki bezpieczeństwa oraz dostarczy Zleceniodawcy finalny raport z automatycznego audytu wykonanego tym narzędziem. Gwarancja Wykonawca będzie odpowiedzialny za bezpłatne aktualizacje oraz rozwiązywanie problemów związanych z działaniem aplikacji, których przyczyna leży po stronie wykonawcy, w okresie 2 lat od momentu wykonania Dzieła. Szczegółowe warunki SLA są zawarte w załączniku nr 13 do SIWZ. Zmiany wynikające z woli Zleceniodawcy, będą każdorazowo wyceniane przez Wykonawcę i wykonywane w drodze osobnych ustaleń. Oferta powinna zawierać cennik godzinowy Wykonawcy. Wersja mobilna 13/20

14 Serwis poza responsive layout, powinien mieć przygotowaną wersję mobilną serwisu z osobnym layoutem. Wersja mobilna powinna umożliwiać użytkownikowi przełączenie się z powrotem to standardowej wersji serwisu, i pamiętać ten wybór. Wersja dla niepełnosprawnych Serwis powinien umożliwiać przełączenie serwisu do wersji o wysokim kontraście oraz powinien wspierać standard Aria, prawidłowo definiować nawigację po elementach serwisu za pomocą tabindex oraz ukrywać w wersji dla niepełnosprawnych zbędne elementy interfejsu, które mogłyby zaburzać pracę czytników bądź nawigację osób niepełnosprawnych po stronie. Wersja żałobna serwisu Serwis powinien zawierać specjalny zestaw styli dla wersji żałobnej serwisu, którą można będzie włączyć z poziomu panelu administracyjnego systemu. Wersja żałobna powinna zmieniać także paletę kolorów dla obrazków wyświetlanych na stronie. Multisite System powinien obsługiwać wiele domen/subdomen bez konieczności stawiania osobnej kopii aplikacji. Solr powinien wiedzieć, że dany artykuł jest z konkretnej domeny i umożliwiać filtrowanie po tym polu. ACL systemu powinien umożliwiać sterowanie dostępem użytkownika do konkretnej domeny z różnymi poziomami uprawnień - przykładowo, ten sam użytkownik może być redaktorem naczelnym jednego z podserwisów, ale na innym serwisie ma pozycję redaktora. Wielojęzykowość System powinien umożliwiać tworzenie wielu wersji językowych danej strony. Powinien pozwalać na tłumaczenie artykułów ale także na pisanie zupełnie niezależnych treści dla danej wersji językowej. Interfejs serwisu powinien być w pełni przetłumaczony na języki angielski i polski oraz umożliwiać tłumaczenie na inne języki. Serwis powinien w pełni wspierać cyrylicę, języki azjatyckie oraz języki pisane od prawej do lewej. Projekty lokalne i submarki Ponieważ część migrowanych serwisów, to tzw. submarki, przykładowo azja.iam.pl która trafi do azja.culture.pl, w systemie będą się pojawiały artykuły pisane w wielu językach. 14/20

15 Projekt zakłada, że na stronie culture.pl będą publikowane artykuły jedynie w językach polskim i angielskim, a pozostałe języki będą występowały w subdomenach. Jednocześnie, jeden artykuł może być napisany w kilku językach, i artykuł na culture.pl, który jest tłumaczeniem artykułu np. z azja.culture.pl, powinien dawać możliwość powiązania tych dwóch tłumaczeń redaktorowi, a frontend serwisu powinien wyświetlać linki do wersji artykułu we wszystkich możliwych językach. W tym przypadku nie jest wymagane automatyczne tworzenie powiązań pomiędzy artykułami, ponieważ mogą one powstawać w nieskoordynowany sposób. Wystarczy możliwość dodawania powiązań poprzez autora. Powiązanie to, powinno być automatycznie pokazywane także w pozostałych wersjach językowych artykułu w panelu edycji wpisu, aby nie trzeba było wykonywać tej pracy wielokrotnie, osobno dla każdej wersji językowej. Różnice layoutowe między submarkami Submarki, co widać na przykładowym projekcie, nie będą znacząco odbiegały wyglądem ani funkcjonalnościami od serwisu culture.pl. Zleceniodawca zakłada, że konfiguracja danej submarki, czyli de facto kolejnej domeny obsługiwanej przez system, będzie pozwalała na konfigurację pewnych elementów graficznych tej domeny, takich jak: kolorystyka globalny kolor czcionki kolory nagłówków kolor tła logotyp tło strony tło nagłówka strony Każda submarka będzie także posiadała własne menu. System oceny pracy autorów Schemat pracy autora treści i rozliczania tej pracy, przedstawia poniższy schemat. 15/20

16 Szczegółowy opis: 1. Redaktor wciska przycisk Dodaj nową zawartość strony. System zapamiętuje godzinę rozpoczęcia pracy nad artykułem. 2. Redaktor przypisuje do artykułu stosowne kategorie: informacyjny, autorski 3. Redaktor zapisuje artykuł jako szkic. System zapisuje czas spędzony na edycji tej wersji artykułu oraz liczbę znaków w artykule. 4. Redaktor opuszcza ekran edycji. W przypadku powrotu do edycji artykułu system zapamięta godzinę rozpoczęcia kolejnej edycji. Jeśli redaktor kontynuuje pracę nad artykułem czas rozpoczęcia edycji liczy się od momentu rozpoczęcia pracy na szkicu. 16/20

17 5. Redaktor publikuje artykuł. System jako czas edycji zapisuje całkowity czas pracy nad szkicem (czyli wcześniej zapisany czas + czas aktualnej edycji). W przypadku, gdy publikacji dokona inny redaktor niż osoba, która stworzyła szkic autorstwo zostanie przypisane redaktorowi, który dokonał publikacji. System jako liczbę znaków zapisuje stan na moment publikacji czyli dane wprowadzone w trakcie pracy nad szkicem oraz te przed samą publikacją. 6. Redaktor dokonuje edycji wcześniej publikowanego artykułu. System zapisuję godzinę rozpoczęcia edycji. 7. Redaktor modyfikuje artykuł i zapisuje jako szkic lub publikuje. System zapisuje czas edycji tej wersji artykułu a jako liczbę znaków zapamiętuje różnicę między poprzednią opublikowaną a aktualną wersją. W przypadku gdy w trakcie edycji redaktor dodał mniej znaków niż usunął system zapisze to jako 0 znaków. Takie przypadki będą analizowane oddzielnie na etapie rozliczeń. 8. Na koniec okresu rozliczeniowego redaktor generuje raport. System wyświetli na liście sumę czasu spędzonego na tworzeniu i edycji artykułów ze wszystkich wersji, które powstały w danym okresie rozliczeniowym. System wyświetli na liście sumę znaków dodanych przez redaktora w trakcie tworzenia i edycji ze wszystkich wersji, które powstały w danym okresie rozliczeniowym 9. Redaktor naczelna oznacza wybrane artykuły z raportu jako autorskie plus poprzez nadanie im kategorii autorskie plus. 10. Redaktor jest rozliczany z liczby znaków wprowadzonych w danym okresie rozliczeniowym w kategorii informacyjne, autorskie oraz autorskie plus. Uprawnienia związane z rozliczaniem czasu pracy Użytkownicy o roli Redaktor mają uprawnienia do: Podglądu swoich statystyk ogólnych (sumy) Podglądu swoich statystyk szczegółowych (podział na każdą wersję artykułu) Dodawania kategorii: informacyjne, autorskie Użytkownicy o roli Redaktor-Admin mają uprawnienia do: Podglądu statystyk ogólnych (sumy) dowolnego użytkownika Podglądu statystyk szczegółowych (podział na każdą wersję artykułu) dowolnego użytkownika Dodawania kategorii: informacyjne, autorskie, autorskie plus Statystyki przyrostu treści System powinien pozwalać na wygenerowanie raportów dotyczących przyrostu treści w serwisie. Chodzi tutaj o raport, pokazujący liczbę/przyrost treści w danym czasie. Podobnie jak 17/20

18 w przypadku statystyk autorów, raport przyrostu treści powinien pozwalać na generowanie raportu z podziałem na: 1. okresy czasu - rok, miesiąc, dzień, zakres daty 2. typy treści 3. język 4. sumaryczna liczba treści 5. przyrost treści Panel administracyjny Panel administracyjny systemu musi być funkcjonalny i użyteczny. Przykładem panelu który w opinii Zleceniodawcy będzie wymagał nieznaczących zmian jest panel systemu drupal. Wszelkie pola w formularzach służących do tworzenia treści bądź edycji struktury serwisu, powinny mieć wbudowaną pomoc w trybie inline - czyli pojawiające się w dymkach podpowiedzi dokładnie opisujące co należy wprowadzić w danym polu. Dokumentacja pól nie może być tylko i wyłącznie zawarta w osobnej sekcji systemu. Wszelkie pola formularza powinny mieć ustawione konkretne typy i obsługiwać walidację zarówno na poziomie javascript, jak i po stronie systemu. Przepływ zadań/schemat publikacji System powinien umożliwiać zarządzanie przepływem zadań między użytkownikami. Artykuły przed publikacją, przykładowo wymagają korekty przez korektora, kontroli ze strony tłumacza oraz zatwierdzenia przez redaktora. System powinien pozwalać na co najmniej częściową automatyzację tego procesu i odpowiednie ograniczenie uprawnień do danego artykułu dla danego typu użytkownika. Właściwości systemu CMS Zadeklarowany w ofercie system CMS powinien spełniać następujące wymagania: Zarówno kod samego systemu jak i kod wszelkich wykorzystanych wtyczek powinien być dostępny na zasadach Open Source (licencja typu GPL). Nie jest dopuszczalne wykorzystanie komercyjnych wtyczek, lub wtyczek, które w wersji otwartej/darmowej realizują jedynie część funkcjonalności dostępnych w płatnej wersji wtyczki System powinien natywnie wspierać replikację baz danych oraz silniki RBDMSinne niż MySQL System powinien natywnie wspierać mechanizmy key-value store (memcached, redis) System powinien posiadać dużą i aktywną społeczność, objawiającą się: dużą liczbą użytkowników społeczności na świecie ( ponad użytkowników) dużą liczbą aktywnych instalacji w sektorze największych stron w zestawieniu serwisu builtwith.com pod adresem 18/20

19 Wszelkie moduły/pluginy wykorzystane przy wytwarzaniu serwisu, powinny wykorzystywać warstwę abstrakcji dostarczaną przez CMS System powinien umożliwiać prowadzenie blogów dla konkretnych użytkowników System powinien umożliwiać budowanie nielimitowanej liczby hierarchicznych taksonomii, włącznie z możliwością ustawiania kolejności elementów w drzewie i jego gałęziach System powinien umożliwiać tworzenie profili użytkowników, dodawanie do nich pól oraz pozwalać na kontrolę wyświetlania tych pól za pomocą graficznych paneli zarządzania tymi polami System powinien pozwalać na dynamiczne tworzenie widoków dla typów treści: kategorii zawartości stron (dla wszystkich typów zawartości zdefiniowanych w systemie) użytkowników plików danych przesłanych przez formularze w formie: tabel, list HTML, kanałów rss (xml), niesformatowanych list menu z możliwością: sortowania po dacie (asc,desc), tytule, bądź po dowolnym innym polu wyświetlanym, bądź nie wyświetlanym widoku filtrowania po właściwości danego pola ustawiania dodatkowego nagłówka i stopki dla danego widoku stronnicowania wyników, z kontrolą liczby elementów wyświetlanych na jednej stronie nadpisania wyników działania mechanizmu w przypadku braku wyników eksponowania filtrów które zostały użyte do wyświetlenia danego widoku w celu umożliwienia użytkownikowi zmiany wartości danego filtra zapisywania wyników działania mechanizmu w pamięci podręcznej (cache) System powinien umożliwiać edycję pól formularza dodawania treści, w panelu zarządzania systemu. Formularze te nie mogą być zakodowane na stałe w systemie. System powinien umożliwiać zarówno zmianę typu tych pól, jak i ich obowiązkowości, grupowania oraz położenia w formularzu System powinien korzystać z najbardziej popularnej na rynku biblioteki javascript - jquery System powinien pozwalać na granularne zarządzanie uprawnieniami użytkowników, z podziałem na: możliwość dodawania/usuwania/edycji danych typów treści z podziałem na: treści własne treści utworzone przez inne osoby poziomy użytkowników, dynamicznie zarządzane z poziomu panelu CMS 19/20

20 osobno udzielany dostęp do funkcji każdego modułu/pluginu System CMS powinien umożliwiać z poziomu panelu administracyjnego, definiowanie własnych typów treści, wraz z możliwością dodawania do nich własnych, dodatkowych pól, z których każde może mieć osobne właściwości, nie ograniczane odgórnie przez typy dostępne początkowo w systemie. To znaczy, że system powinien przykładowo pozwalać na dodanie typu treści sylwetka z wieloma polami typu: wartość bool (0/1) tekst tekst z wypisem liczba całkowita liczba dziesiętna liczba zmiennoprzecinkowa lista numeryczna lista tekstowa obraz link plik odnośnik do terminu (taksonomii) z możliwością wyboru dla każdego pola trybu wprowadzania w formatach: lista pojedynczego wyboru lista wielokrotnego wyboru dowolna wartość automatycznie dopełniane pole tekstowe (w przypadku taksonomii/słowników) 20/20