Specyfikacja techniczna Culture.pl

Specyfikacja techniczna
Culture.pl
1/20
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
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
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
●
●
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
●
●
●
●
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
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
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
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 email, użytkownicy typu moderator, mają możliwość aktywowania
konta takiego użytkownika.
9/20
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
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 http://www.iam.pl 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
emailowym 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
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
http://www.openx.com/docs/tutorials/single+page+call
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
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 11211 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
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
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
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
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
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 600000
użytkowników)
○ dużą liczbą aktywnych instalacji w sektorze 10000 największych stron w
zestawieniu serwisu builtwith.com pod adresem http://trends.builtwith.com/cms
18/20
●
●
●
●
●
●
●
●
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
●
○ 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