Problemi sa hosting serverima i sajtovima

U ovom članku pisaću o problemima sa sajtovima i hosting serverima na koje sam nailazio tokom godina, kao i o (utvrđenim) uzricima tih problema i njihovim rešenjima. Zamišljen je u formi niza “problem – odgovor”, koji će se godinama dopunjavati, ažurirati. Da sve bude na jednom mestu, relativno lako pretraživo. Gde god to nije od ključnog značaja, neću navoditi konkretne sajtove, niti hosting provajdere, ili tipove servera – kako bi podaci bili što sažetiji i što lakši za pretragu.

Za pitanje-odgovor koristiću format “FAQ”, koji omogućava Yoast SEO plagin (batalio sam Yoast i prešao na The SEO Framework). Za razliku od samog WordPress-a, Yoast-ov FAQ pravi blokove u schema.org kompatibilnom formatu (opširnije o tome sam pisao u članku o WordPress 5 i Gutenberg editor). No, da pređemo na stvar.

Sadržaj:
Uvod – Zlatno pravilo

1. “403 Forbidden” greška
2. Problem sa dostavom mejlova, tipa a
3. Connection refused PHP greška
4. Ne šalju se mejlovi iz WordPress-a i druge aplikacije
5. WordPress sajtovi ne daju logovanje u bekend – PHP!
6. Problem sa unošenjem skupa slova na WordPress sajt
7. Problem sa izmenom/ažuriranjem WordPress vidžeta
8. Čudan problem sa Cloudflare

1. Zlatno pravilo

Uvek, ali uvek proverite sve na svojoj strani, prvo.

• Da li vaša Internet konekcija radi normalno za ostale sajtove?
• Je li vam računar možda ima neki virus?
• Jeste li platili sve račune?

Zatim proverite status servera/mreže hosting provajdera:

Više detalja o ovome napisao sam u članku o teh. podršci.

Tek nakon toga, probajte instrukcije napisane ispod, u zavisnosti od problema sa kojim se suočavate:

– Sadržaj –

Problem 1 – “403 Forbidden” greška

Kada pokušam otvoriti stranicu sajta, dobijam:
“403 Forbidden
Access to this resource on the server is denied!”

Prva stvar koju treba proveriti je blokirana IP adresa od strane WAF-a hosting provajdera (Web Access Firewall).
Ovo se može lako proveriti tako što se pokuša konekcija putem VPN-a, sa drugom IP adresom (može i TOR browser da se koristi u tu svrhu), ili korištenjem Internet mreže provajdera mobilne telefonije, sa pametnog telefona (ne preko kućnog/poslovnog Wi-Fi, pošto će tada verovatno biti ista IP adresa kao i na računaru).
Ako tada sve radi normalno, znači da treba deblokirati svoju IP adresu iz kontrol panela hosting provajdera. Kada se ulogujete na panel i izaberete meni kao na slici ispod, obično vaša IP adresa bude automatski detektovana. Ako to nije slučaj, koristite whatismyip.com.

Šta ako konekcija preko druge IP adrese takođe ne radi? Naredna slika daje uputstvo za prvi korak:

Ako vaš server/mreža nisu na spisku trenutno “problematičnih”, onda jedino ostaje da se obratite tehničkoj podršci provajdera, da utvrde u čemu je problem i reše ga. Kada pišete tiket, objasnite da ste proverili status servera/mreže i da ste pokušali konekciju sa (barem) dve različite IP adrese. Najverovatnije je problem do WAF (ModSecurity) pravila servera, ali moglo bi biti i nešto treće.

– Sadržaj –

Problem 2 – Problem sa dostavom mejlova, tipa a

Imam više domena (sajtova) i mejlovi sa (barem) jednog od njih ne stižu na drugi (druge)

Kada se domen postavi na jednom hosting serveru, server će mejlove upućene tom domenu, a poslate sa domena hostovanih na istom serveru, pokušavati proslediti na isti server. Čak i ako se domen (sajt) migrira na drugi server (kod drugog hosting provajdera), svi mejlovi poslati sa istog (starog) servera, biće dostavljani lokalno.
Ako obrišete domen i inbox za dati mejl, može se desiti da mejlovi budu samo odbijeni (bounce nakon pokušaja dostave na isti server).

Na primer, bikegremlin.com i io.bikegremlin.com su na serveru A.
Premestim bikegremlin.com na server B.
Šaljem mejl sa [email protected] na [email protected] i taj mejl ne stiže gde treba (biva dostavljen na server A, a ako obrišem bikegremlin.com sa servera A, stiže bounced izveštaj o grešci).

Rešenje: pre migracije podesiti mejlove da idu preko eksternog servisa. Ako se koristi eksterni mejl servis, ovo bi svakako trebalo podesiti, čak i ako se ne premešta sajt. Sledite uputstvo za podešavanje eksternog mejl servisa.

– Sadržaj –

Problem 3 – Connection refused PHP greška

S vremena na vreme nije loše proveriti sadržaj direktorijuma u kojem se sajt nalazi na hostin serveru (lokacija sajta i error logova na cPanel i DirectAdmin kontrolnim panelima). Prilikom pregleda primetio sam da se fajl za greške PHP-a (error_log u cPanel-u) puni ovakvim linijama:

[19-May-2020 18:33:14 UTC] Connection refused
[19-May-2020 18:35:15 UTC] Connection refused
[19-May-2020 18:37:16 UTC] Connection refused
[19-May-2020 18:38:15 UTC] Connection refused

Nova linija se upisuje svakih minut, ili kraće. OK, nešto pokušava da se nakači negde i ne uspeva. 🙂 Ovako je išlo moje utvrđivanje uzroka problema:

U pitanju je bio WordPress sajt.

Imam identične kopije sajta – dve na istom i jednu na drugom hosting serveru (druga kopija na istom serveru služi za testiranje brzine i optimizacije sajta i plaginova – radi lakšeg poređenja). Ovakve identične kopije sajtova se zovu stejdžing (eng. “staging”) sajt. Korisne su za testiranje stvari pre stavljanja ih na pravi (“produkcioni”) sajt.

Zahvaljujući tome, mogao sam proveriti da li se problem javlja na drugom, istom takvom sajtu (ista WordPress tema, plaginovi i sadržaj) na istom serveru, kao i da li se javlja takođe i na drugom serveru. Utvrdio sam da se na drugom serveru ne javlja, pa sam zaključio da je problem najverovatnije sa hostingom, a ne sa sajtom/temom/plaginovima.

Tada sam se obratio tehničkoj podršci hosting provajdera i, kao što sam očekivao, rekli su da je problem najverovatnije do nekog WordPress plagina. Što me je podestilo na sličan scenario koji sam opisao u članku o tehničkoj podršci hosting provajdera – nazvao sam ga “Kvaka 22”. Uglavnom, tehnička podrška je predložila da isključim sve plagine, pa testiram jedan po jedan, da vidim kada će se greška pojaviti.

OK, shvatio sam da ću morati sam da “kopam” malo. I uradio sam to – jasno je da moram otkriti koji plagin pravi problem i dati tehničkoj podršci više informacija. Ovo ni na koji način nije kritika tehničke podrške. Zaista je premalo informacija za rešavanje problema, dok tehnička podrška uglavnom ima desetine tiketa za podršku u svakom trenutku (videti tehnička podrška telefonom naspram tiketa).

Uključivanjem po jednog plagina dok su ostali deaktivirani, utvrdio sam da LiteSpeed cache plagin pravi probleme (zašto je LiteSpeed za mene najbolji opisao sam u članku o keširanju WordPress sajta). Kako bih bio siguran, aktivirao sam sve ostale plagine, osim LiteSpeed cache, da vidim je li se tada javlja problem – nije se javljao.

Javio sam to tehničkoj podršci, ali nije bilo dovoljno za rešavanje problema, tako da sam se udubio u podešavanja/opcije “problematičnog” plagina, tražeći šta ga navodi da stalno pokušava neuspešne konekcije. Ušao sam u meni za keširanje:

Ko god da je pravio plagin, uradio je odličan posao:

Jasno je napisano obaveštenje o uzroku problema. Memcached piše “Disabled” (1) pošto sam tu PHP ekstenziju isključio u PHP opcijama na serveru, jer je ne koristim. Ali test konekcije (2) pogazuje problem sa izabranim Redis-om. Klik na link pored tog izveštaja lepo sve objašnjava – “Learn More“.

Kada sam to preneo tehničkoj podršci, reinstalirali su Redis servis (za koji kažu da su tada utvrdili da posle apdejta nije radio kako treba) i sve je radilo kako treba. 🙂

– Sadržaj –

Problem 4 – Ne šalju se mejlovi iz WordPress-a i druge aplikacije

Trudim se držati ovu rubriku “anonimnom” – iz mog iskustva, mnogi problemi su “univerzalni”, pa ne bih da “nepravedno” pravim lošu reputaciju za bilo koju kompaniju. Ovde sam ipak naveo sve provajdere i plagine, sa dobrim razlogom: za slučaj da je problem do blokiranja odrđenog opsega IP adresa, ili nekompatibilnosti određenih funkcionalnosti. Ovaj tekst služi za pomoć tehničkoj podršci u tome da reši problem.

a)

Koristim MXroute servis za mejlove. Radi lakšeg korištenja pri dopisivanju, povezao sam mejl nalog sa Gmail-om.
I ovo radi bez problema.

b)

Podesio sam bio WordPress slanje mejlova preko SMTP servisa MXroute, koristeći Easy WP SMTP plagin, kako se ne bih oslanjao na nepouzdane WordPress mejling funkcije.
Ovo je prestalo raditi. Problem sam primetion 30. maja 2020.
Greška koju dobijam kada šaljem test mejl:

SMTP ERROR: Failed to connect to server:  (0)SMTP connect() failed. https://github.com/PHPMailer/PHPMailer/wiki/Troubleshooting

c)

Za WordPress mejling liste koristim Newsletter plagin. Podešen je da isto koristi MXroute SMTP (ne ide preko drugih plaginova za slanje mejlova, niti preko WordPress mejling funkcija).
Ovo radi.

d)

Koristim (u fazi testiranja, imam nekih dilema, ali to ovde nije tema) aplikaciju InfiniteWP za nadzor WordPress sajtova (uz plagin InfiniteWP Client instaliran na sajtovima koji se nadziru – pomoću kojeg se WordPress sajt “javlja” aplikaciji). Aplikacija je instalirana na hosting serveru, i podešena da koristi MXrotue SMTP za slanje mejlova.
Ni u ovoj aplikaciji slanje mejlova sada ne radi.

h1)

Jedan od hostinga koje koristim je HostMantis (moja ocena & iskustvo).

h2)

Drugi hosting koji koristim je MyW.pt (moja ocena & iskustvo).

Ponašanje je isto na više servera i sajtova (svim sajtovima), kod oba navedena hosting provajdera.

e)

Za probu, kada se problem javio, instalirao sam drugi plagin za SMTP slanje mejlova: WP Mail SMTP by WPForms (isključio sam prethodno korišteni SMTP plagin).
Ni ovaj plagin ne radi.
Greška koju dobijam pri slanju testnog mejla:

Could not connect to the SMTP host.

This means your web server was unable to connect to friday.mxlogin.com.

Typically this error is returned for one of the following reasons:

-SMTP settings are incorrect (wrong port, security setting, incorrect host).
-Your web server is blocking the connection.
-Your SMTP host is rejecting the connection.

Recommended next steps:
Triple check your SMTP settings including host address, email, and password, port, and security.
Contact your web hosting provider and ask them to verify your server can connect to friday.mxlogin.com on port 465 using ssl encryption. Additionally, ask them if a firewall or security policy may be preventing the connection - many shared hosts block certain ports.
Note: this is the most common cause of this issue.
Contact your SMTP host to confirm you are using the correct username and password.
Verify with your SMTP host that your account has permissions to send emails using outside connections.

f)

Proverio sam error logove servera kod oba provajdera – nema prijavljenih (PHP) grešaka (lokacija error logova u DirectAdmin-u i cPanel-u).

g)

Objasnio sam sve ovo na sličan način HostMantis i MyW.pt tehničkoj podršci, a postovao sam opis problema i na MXroute forumu za podršku. Na tom forumu sam dobio povratnu informaciju drugog korisnika, koji je isto kod MyW.pt, ali koristi drugi MXroute server – korsiniku sve radi.

h)

Probao sam slanje mejla preko sajta koji koristi SMTP hosting provajdera (a ne MXroute).
Sve radi.

i)

Konačno – isprobao sam sa sajta koji je na istom hostingu, ali koristi drugi MXroute server (ali je isto preko MXroute).
Tu isto sve radi.
Ali, dok sam se setio to probati, proradilo je i sve ostalo.

Moje razmišljanje (pretpostavke) o potencijalnom uzroku problema:

• Pošto a) i c) rade – na oba servera, na svim sajtovima, pretpostavljam da MXroute sam po sebi radi OK.
• Pošto b) i e) ne rade ni na jednom serveru, na više sajtova, pretpostavljam da problem može biti vezan za stack koji koriste oba provajdera (CloudLinux, PHP 7.3, LiteSpeed – ili nešto četvrto), ili neki firewall blokira pristup MXroute.
  d) sam testirao samo na h2), tamo ne radi, pa zbog toga takođe sumnjam na ovaj problem.
• Nije nemoguće, ali je malo verovatno, da su b), d) i e) prestali raditi zbog problema (sa plaginima i aplikacijom) svi u isto vreme.
• g) i h) me navodi na to da možda neki firewall blokira određeni MXroute server. Nisam siguran – nisam ekspert.
• i) navodi na to da je postojao neki problem sa MXroute – osim ako su oba provajdera nešto namestili, a da niko od njih nije javio. Ali (za) sada sve radi. 🙂

Postavio sam pitanje i na forumu za podršku Easy WP SMTP plagina – za slučaj da njima nešto padne na pamet (iako ne mislim više da je do plagina – kako sam i dopisao tamo).

I poslao sam link ka ovom pisaniju i tehničkim podrškama hosting provajdera i MXroute – ako njima nešto pomogne.

Proradilo je ponovo, nakon kraćeg “štucanja”. MXroute sugeriše da je ovo moglo biti uzrok:
https://forums.cpanel.net/threads/intermediary-ca-certificate-expiration.673165/

– Sadržaj –

Problem 5 – WordPress sajtovi ne daju logovanje u bekend – PHP!

Čudan problem. WordPress sajtovi ne rade, dok ostali sajtovi na istom reseller hosting nalogu svi rade. Ovo obično nastaje usled problema sa plaginom – u 99,999% slučajeva. Međutim, deaktiviranje svih plaginova nije rešilo problem. Dok sajt kada se klonira, ili migrira na drugi server – radi bez problema.

Zbog ove poslednje stavke isključio sam Cloudflare i WordPress sam po sebi kao potencijalne uzroke problema.

Postojalo je i konstantno opterećenje od tačno 13 entry procesa na svakom WordPress sajtu. Sumnjao sam na problem sa Mod Security, ali njegovo isključivanje nije pomoglo.

Meni dostupni logovi sa greškama nisu dali odgovor.

Na kraju, teh. podrška provajdera je utvridila da je update softvera za zaštitu, Imunify360, pravio probleme sa PHP 8.0. Zbog toga su ne-WordPress sajtovi radili lepo – ili ne koriste PHP, ili koriste starije verzije. Dok su moji WordPress sajtovi svi prešli na PHP 8.0.

– Sadržaj –

6. Problem 6 – Problem sa unošenjem skupa slova na WordPress sajt

Dok sam pisao uputstvo za postavljanje slika u komentar na sajtu/forumu, prilikom unošenja adrese sajta “imgbb .com,” dobijao sam ovu grešku (i članak nije hteo da se sačuva, ažurira, niti objavi):

“Updating failed. The response is not a valid JSON response.”

Probao sam uraditi isto na staging sajtu koji je kod drugog hosting provajdera. Tu je prošlo bez problema.

Vraćam se na “problematični” sajt i otvaram konzolu u Chrome browser-u da vidim kakva je tu situacija. Ova greška se prikazivala:

“Failed to load resource: the server responded with a status of 403 ()”

OK, problem najverovatnije nije do WordPress-a, već ima neke veze sa zaštitom hosting servera.

Odlučujem otvoriti tiket za podršku kod svog hosting provajdera (HostMantis). Objasnim šta se dešava i kliknem dugme za slanje tiketa… i ponovo dobijem 403 grešku! Na konzoli hosting provajdera. 🙂

OK, definitivno je problem do njih.

Zatim sam ponovo otkucao tiket, praveći razmak između reči “imgbb” i “.com” – kao što radim i u ovom članku.

Odgovorili su da isključim ModSecurity pravilo koje se okida pri ažuriranju članka koji sadrži “problematičan” string – i da je to sve OK što se njih tiče.

Sad, ne bih sebe nazvao vrhunskim ekspertom za bezbednost Linuks servera, ali besmisleno mi je da se zaštita “okida” pri unosu običnog teksta, ili/i običnog hiperlinka.

Ne želim isključivati zaštitu, ni privremeno, samo da bih najnormalnije ažurirao najobičnije članke. Ovaj provajder me služi fenomenalno još od 2019. godine – stabilnost, brzina, pa i zaštita, ali vrlo sam nezadovoljan ovom polisom i načinom na koji su “rešili” ovaj tiket. Prvi put ikada da sam odgovor na tiket podrške ocenio najnižom ocenom.

Čekam ponedeljak da u firmu dođe neko ko zna šta radi, i moooožda baci oko na tiket. Mada su ga već zatvorili, što se njih tiče sve je OK.

– Sadržaj –

Problem 7 – Ne mogu ažurirati/izmeniti WordPress vidžete

Javio mi se problem po simptomima sličan (identičan) problemu 6. Ovaj put kada pokušam izmeniti i ažurirati WordPress vidžete (u back-end-u). Pri pokušaju snimanja izmena, dobijao sam ovu poruku:
“There was an error. The response is not a valid JSON response.”

Probao sam sve – isključivanje plaginova, Cloudflare-a, ModSecurity, brisanje keša…

Sad, bikegremlin.com sajtovi koriste Cloudflare Pro. Tako da sam probao sa stejdžing kopijom koja to ne koristi. Međutim, problem pri copy-paste Google AdSense koda se i tu ponavljao! Da probam sa drugim hosting provajderom/serverom? Isto!

Onda sam cimao i tehničku podršku provajdera, da vide ima li slučajno nešto da oni mogu uraditi.
Da stvari budu još gore, to je zaista vrhunska tehnička podrška, pa su se zaista pomučili, i ostalo je na tome da im napravim WordPress login nalog, na sajtu ili stejdžingu, pa da traže problem dalje… nema “sve je OK kod nas, teraj se” kod MDDHosting-a!

Otišao sam bajsom do radnje, i razmišljao usput. Pri povratku, pokušao sam ubaciti običan HTML kod na bikegremlin.com sajt vidžet – link ka slici, bez ikakvih skripti. Ni to nije radilo. Pokušao sam isto na stejdžing kopiji – radi! OK, isti plagini, tema, isti provajder. Šta je različito?

Kod child tema se razlikuje! Produkcioni sajtovi imaju Google AdSense kod dodat u child temi. Bacio sam oko na browser konzolu i potvrdio da se crveni (403) kod vezan za AdSense kada radim na vidžet stranici u bekendu. Onda sam uradio najgluplju stvar:

Aktivirao sam AdGuard AdBlocker!

I to je rešilo problem. 🙂 Bilo je do AdSense sve vreme.

Ažuriranje – problem se vratio. AdBlocker više ne pomaže. Jedino rešenje za sada je brisanje svog AdSense koda sa sajta.

Nakon dodatnog testiranja sa različitim klonovima, stejdžing kopijama (i različitim browserima, sa isključenim svim ekstenzijama) i sl, zaključujem da je ipak problem do Cloudflare Pro. Samo je potrebno 15 do 25 da se isključivanje njihovog proksija i brisanje keša propagira. To je poremetilo moje inicijalne pokušaje utvrđivanja uzroka problema. Uglavnom, kada sklonim sajt sa Cloudflare, sve radi normalno.

Otvaranje konzole browsera daje sledeću sliku pri otvaranju stranice sa vidžetima i pokušaju ažuriranja custom HTML vidžeta:

Obratio sam se Cloudflare tehničkoj podršci u vezi ovoga. Čekam da vidim imaju li ideja. Cloudflare “Bot fighting mode” je sve vreme isključen.

Podrška je brzo skontala koje firewall pravilo je ovo blokiralo:

Security -> WAF -> Managed rules -> Cloudflare Managed Ruleset -> Cloudflare Specials ->
Service Managed rules
Rule ID 100173
Rule message XSS, HTML Injection – Script Tag

Odlučio sam da probam podesiti to pravilo na “challenge” i vidim hoće li to pomoći, ili ga moram baš (privremeno) isključiti kako bih ažurirao vidžete:

Meni je loše dizajniran – treba kliknuti 26 puta da bi se došlo do ovog ekrana.

“Challenge” nije pomoglo, tako da sam pokušao isključivanje tog pravila. Nije ni to pomoglo, pa sam pokušao sa isključivanjem celog seta “Cloudflare Specials” pravila – to je samo jedan klik. I dalje ne radi. 🙁

Ralf i Steva sa LowEndSpirit foruma su predložili da editujem hosts fajl radi testiranja (link ka LES forumu) – da direktno pristupim sajtu (zaobilazeći Cloudflare). To ne ide tako lako – ne sa WordPress-om na shared hosting okruženju i sa podešenim HTTPS protokolom.

Rešenje:
Igrao sam se još malo sa firewall pravilima. Pored isključivanja “Cloudflare Specials,” morao sam podesiti OWASP Sensitivity na “Off” – privremeno, dok ne ažuriram vidžete.

Security -> WAF -> Managed rules -> Package: OWASP ModSecurity Core Rule Set ->
Sensitivity: Off

Ove promene se propagiraju praktično trenutno!

Cloudflare i MDDHosting tehnička podrška i društvo sa LowEndSpirit foruma su bili u pravu što su odmah posumnjali na Cloudflare firewall kao uzrok problema. Nisam to odmah bio uvideo, a posle mi je trebalo vremena da skontam koje tačno pravilo pravi problem.

Ažurirao sam svoj Cloudflare Pro i WordPress APO tutorijal sa ovim informacijama – ako se još nekom desi sličan problem.

– Sadržaj –

Problem 8 – Čudan problem sa Cloudflare

HetrixTools je moj omiljeni uptime monitor. Jutros sam pokušao otvoriti stranicu sa svog biciklističkog sajta na srpskohrvatskom, i video grešku 524. Međutim, HetrixTools je pokazivao da je sajt online?!

Taj sajt koristi istu WordPress temu i plaginove kao i moj engleski biciklistički sajt, ali nije na istom serveru. Proverim: engleski sajt radi bez problema.

OK, pomislio sam da možda firewall blokira moju IP adresu. Pokušao sam preko VPN-a (sa engleskom IP adresom). Pošto ni to nije pomoglo, pokušao sam sa druge lokacije (drugi računar i ISP), kako bih sa većom sigurnošću eliminisao mogućnost da je problem do računara ili IP adrese.

Pošto ni to nije pomoglo, pokrenuo sam Uptrends alat, koji testira dostupnost sa velikog broja različitih lokacija. Engleski sajt je radio sa svih lokacija, dok sajt na srpskohrvatskom nije bio dostupan iz Londona i sa još par lokacija.

Ponovio sam testove nakon isključivanja Cloudflare proxy-ja za srpskohrvatski sajt. Gle čuda – oba sajta rade sa svih lokacija! Re-aktiviranje Cloudflare-a je vratilo problem.

Izgleda da Cloudflare blokira pristup serveru sa određenih lokacija (između ostalog i iz Srbije i Engleske – što objašnjava zašto moj VPN nije pomogao).

Obratio sam se hosting provajderu za pomoć i preneo dostupne informacije. Sugerisali su da je možda do WordFence. Deaktivirao sam WordFence, ali problem je ostajao (dok god je Cloudflare proxy aktivan).

Posle nekoliko sati, provajder je predložio premeštanje mojih naloga na drugi server (iz Nemačke –Hetzner, u Englesku -OVH).

Čudan problem. Zanimljivo mi je što HetrixTools nije registrovao probleme sa sajtom, čak ni sa njihove lokacije u Londonu. Poslaću link ka ovom tekstu HetrixTools-u, za slučaj da im bude interesantno.

U trenutku pisanja problem je rešen migracijom mojih naloga na drugi server, u Engleskoj.

Ažuriranje:
Problem se ponovo bio javio na engleskom serveru. Ovaj put smo malo više lupali glavu i skontali da je problem bio do Cloudflare Railgun-a. Glavni domen je na hosting serveru koji podržava Railgun, ali poddomen je na engleskom serveru koji ne podržava Railgun. Tako da je isključivanje Cloudflare Railgun-a rešilo problem, bez potrebe za isključivanjem kompletnog Cloudflare proxy-ja. 🙂

– Sadržaj –