marv

To może być pewien trop, ale z drugiej strony przecież nie dodaję żadnej niedozwolonej komendy, a składnie są w porządku. Dla przykładu to wciąż ten sam plik, powiedzmy, że chciałem usunąć jedną linijkę kodu, żeby coś sprawdzić, a potem ponownie ją wrzucić i w efekcie nie działa. Czy czasem nie jest to robota wtyczki od z iThemes Security? Ona wpisuje w .htaccess całkiem sporo kodu i może po wgraniu nowego htaccess koniecznie jest po prostu restart tej wtyczki. Ostatecznie wygenerowałem sobie nowy htaccess przez perma linki, chociaż gdyby chciał coś wrzucić znowu do htaccess manualnie problem pozostaje.

Też tego nie pojmuję, tym bardziej, że jeszcze przedwczoraj normalnie wrzuciłem plik na serwer o nazwie .htaccess mający format plik i działał. Kwadratura koła Może opisze to inaczej. Rzecz polega na tym, że plik .htaccess musi widnieć w FileZilli jako htaccess-plik i w ten sposób przesłany na FTP, żeby działał na mojej stronie. Wiem, że nie ma takiego fromatu, ale z jakiejś przyczyny tak musi być, żeby działało. Jeżeli prześlę jak wyżej .htaccess widniejący w FileZilla jako PLIK, to strona wyrzuca Internal Server Error, czyli Apache nie widzi tego pliku. Owszem, mogę przecież zapisać sobie np. ABX.htaccess i w ten sposób, widziane przez FileZilla jako htaccess-plik wrzucić to na FTP, ale czy plik htaccess może się tak nazywać? Czy inna nazwa .htaccess niż domyślna, nie spowoduje potem problemów np. w konfiguracji wtyczek, które zapisują coś do tego pliku. Wedle zaleceń powinien nazywać się wyłącznie .htaccess. Jeszcze inaczej zadam pytanie. Dlaczego moja strona nie widzi pliku nazywającego się .htaccess? Teraz najlepsze. Jak wspomniałem wrzucenie normalnego pliku nazwanego .htaccess przez FileZille z jakiegoś powodu powoduje Internal Error i nie jest widziane prze Apache. Zalogowałem się więc na FTP poprzez klienta hostingu i tam zmieniłem nazwę pliku ABC.htaccess na 'htaccess'. Wersja kropka+htaccess nie może być zapisana. W ten sposób klient zmienił nazwę pliku na 'htaccess'. Patrząc na ten plik w File Zilli mamy .htaccess z atrybutem PLIK, ale tym razem działający czy ktoś coś z tego rozumie? bo ja nie.. nigdy wcześniej nie spotkałem się z czymś takim. Podejrzewam, że mąci w tym wszystkim linux..

Cześć, niby problem znany wszystkim, ale tym razem kończą mi się pomysły. Chcę wykonać prostą operację: zaktualizować .htaccess na WP. Problem w tym, że nie mogę tego pliku zapisać ponownie w formacie kropka+rozszerzenie -> .htaccess. Zapisanie txt używając zapisz jako w linuxie daje plik z poprawną nazwą ale w istocie bez rozszerzenia .htaccess Jest to widoczne jako po prostu zwykły plik o nazwie .htaccess. Zmiana nazwy pliku w FileZilla również nie pomaga. Plik może być wyłącznie zapisany jako np. ABC.htaccess (wtedy jego format jest poprawny i widoczny przez serwer) albo ostatecznie ze spacją. Zmiana na pożądaną nazwę kropka+rozszerzenie sprawia, że z formatu htaccess robi się znowu plik. Podobnie dzieje się w FileZilla zmieniając nazwę tego pliku bezpośrednio na serwerze. Przyznam, że już kończą mi się pomysły, a co śmieszniejsze jeszcze kilka dni temu, bez najmniejszych problemów zaktualizowałem ten plik. Do dzisiaj nie wiem dlaczego, ale zostawiłem go wtedy po prostu w formacie 'plik' i był on widoczny przez serwer, a strona nie wywalała błędu 'Internal'. Aktualnie mój plik musi się nazywać np. x.htaccess. Jest on widoczny przez serwer, ale obawiam się, że ma to jakiś wpływ mimo wszystko na jego widoczność przez serwer, ponieważ komendy na Browser Leverage Cache zawarte w nim przestały być brane pod uwagę i strona jest widoczna jako pozbawiona tej funkcji. Znowu namąciłem eh.. Próbowałem również zmienić nazwę tego pliku poprzez terminal w linuxie poprzez komendę mv. Niestety gdy podaje komendę mv ABC.htaccess .htaccess terminal podaje informacje, że nie ma takiego folderu . Poniżej zamieszczam foto z FileZilla jak to wygląda:

Ciekawe spostrzeżenia devopsiarzu. Przy okazji rozmowy o wtyczkach cache, to właśnie dzisiaj po kilku dniowych przejściach ze stroną, pozbyłem się raz na zawsze wp super cache i wcale nie mam ochoty korzystać z jakichkolwiek wtyczek cache. Jaki efekt? Ano taki, że na przykład w PageInsights i GTMetrix witryna dostała 5 oczek więcej. Dziwne? Nie jestem specjalistą, ale wydaje mi się, że dla małej hobbystycznej strony, kompresja i cache po stronie serwera wystarcza, a dokładnie dodatkowych wtyczek, włączanie opcji jest drogą donikąd. Jeżeli działa bardzo dobrze, a w benchmarkach witryna dostaje więcej oczek, to dlaczego szukać dziury w całym?

Dzięki Przemku za linka. Być może te prace miały pewien wpływ, ponieważ od dzisiaj strona śmiga aż miło. Plus całej sytuacji taki, że znowu lepiej poznałem WP, a przy okazji wywaliłem kilka niepotrzebnych wtyczek

Cześć, mam problem związany z optymalizacją strony. Gtmetrix w audycie zaleca mi włączenie browser cache, a page speed insights podobnie jako 'Wyświetlaj zasoby statyczne, stosując efektywne zasady pamięci podręcznej'. Rzecz w tym, że korzystam już z wtyczki WP Super Cache i Autoptimize, które powinny rozwiązać ten problem. Z tego co wyczytałem problem polega na tym, że jedna z wtyczek nadpisuje ustawienia tej drugiej, dlatego oba narzędzia diagnostyczne rekomendują wydłużenie cache powyżej 15 minut. Podobno jednym z rozwiązań jest dodanie do pliku htaccess kodu cache-control i cache-headers (poniżej). Czy to koniecznie, a może można to rozwiązać inaczej z poziomu tych wtyczek? Hosting na OVH. <filesMatch ".(ico|pdf|flv|jpg|jpeg|png|gif|svg|js|css|swf)$"> Header set Cache-Control "max-age=84600, public" </filesMatch> oraz #Customize expires cache start - adjust the period according to your needs <IfModule mod_expires.c> FileETag MTime Size AddOutputFilterByType DEFLATE text/plain text/html text/xml text/css application/xml application/xhtml+xml application/rss+xml application/javascript application/x-javascript ExpiresActive On ExpiresByType text/html "access 600 seconds" ExpiresByType application/xhtml+xml "access 600 seconds" ExpiresByType text/css "access 1 month" ExpiresByType text/javascript "access 1 month" ExpiresByType text/x-javascript "access 1 month" ExpiresByType application/javascript "access 1 month" ExpiresByType application/x-javascript "access 1 month" ExpiresByType application/x-shockwave-flash "access 1 month" ExpiresByType application/pdf "access 1 month" ExpiresByType image/x-icon "access 1 year" ExpiresByType image/jpg "access 1 year" ExpiresByType image/jpeg "access 1 year" ExpiresByType image/png "access 1 year" ExpiresByType image/gif "access 1 year" ExpiresDefault "access 1 month" </IfModule> #Expires cache end Problem rozwiązany. Można albo zainstalować odpowiednią wtyczkę (co mija się z celem) albo wrzucić powyższy fragment do pliku htaccess i ewentualnie dodać rozszerzenia nowych formatów, jeżeli takie mamy na stronie.

Jak widać pod hobbystyczne stronki czasem też się nie sprawdzają Jak kogoś interesuje dalsza historia, to pod wieczór prędkość strony magicznie wróciła do poprzedniego stanu. Bez mojej żadnej ingerencji. Ciekawe co będzie jutro. Najgorsze w tych wszystkich molochach-hostingach jest to, że nie masz tak na prawdę pojęcia co się tam dzieje i możesz zapomnieć, że czegoś się dowiesz, a wystarczy kilka słów, to by człowiek przynajmniej na przyszłość nie szukał tam gdzie nie trzeba i nie tracił czasu

Tak to się zapewne zakończy. To kolejny przykład z życia, że firm gigantów należy unikać. Dopóki wszystko działa nie ma na co narzekać, ale gdy coś nawali to szukaj wiatru w polu i czekaj tygodniami na odp. supportu z tysiącami innych userów. Tym bardziej, że te serwery są zlokalizowane we Francji. Jaki realny wpływ może mieć na nie polski support? Ja mam małą stronę, prowadzę ją hobbystycznie, ale dla kogoś kto prowadzi większy biznes to przecież jakieś nieporozumienie. Dziwnym trafem skończyły mi się zasoby o 4 nad ranem w środku tygodnia. Może żeby 'zachęcić' do wykupienia wyższego pakietu?

Absolutnie nie, chociaż moją wypowiedź można tak zinterpretować. Treść oparta na automatycznym tłumaczeniu zadziała wyłącznie na krótką metę, chociaż może stanowić pomoc albo zmniejszyć nakład pracy, przy rozsądnym użyciu. Podejrzewam, że plugin o którym wspomniałeś również używa wbudowanego translatora. Faktem jest natomiast to, że polska sieć się mocno zapełnienia i żeby pozostać konkurencyjnym, podobnie jak w realnym biznesie, trzeba będzie konkurować ze stronami z całego świata. Wydaje się, że to już chyba ten moment.

Tak się składa, że na tym hostingu mam postawionego drugiego WP zupełnie czystego pod inną domeną i na nim występuje ten sam problem. Obecnie sytuacja wygląda tak, że strony ładują się kilkanaście sekund. Radzisz przenieść się na inny serwer, ale dla mnie jest zaskakujące jak może przytykać się lekki blog na WP tylko z 1000 UU dziennie (ok. 2,5k wyświetleń). Tutaj jest ewidentnie coś nie tak z serwerem. Hosting jest najtańszy, ale powinien sobie radzić z takim ruchem. Dzięki za wtyczkę, Sempre. Przetestuję ją, może dowiemy się czegoś nowego.

Myślę, że trend wielojęzycznych stron, to coś co będzie coraz silniejsze. Uważam, że wprowadzenie kilku języków może dać mocnego boosta do liczby odwiedzin. Pytanie jak to zrobić najlepiej. Nie jestem specjalistą, temat sam zgłębiam, ale ktoś już wspomniał, że powinno się wdrożyć to na href lang. Są jeszcze inne kwestie, po pierwsze jak to zorganizować z technicznego punktu widzenia. Czy w tym przypadku powinniśmy każdą wersję postawić na osobnej instalacji WP? (jeżeli mówimy o WP) i podpiąć do niej domenę? Pozostaje również kwestia tłumaczenia, chociaż zaobserwowałem, że dla dobrze skonstruowanych (napisanych) tekstów, w pewnych branżach, automatyczne translatory dają coraz lepsze wyniki. Co o tym sądzicie?

PHP 7.0. 30 wtyczek, ale wszystkie lekkie lub niezbędne. Sprawdzałem te, które mogą mieć bezpośredni wpływ czyli SuperCache, Autoptimize i iThemesSecurity, ale one nie są winne. Próbowałem jeszcze wgrać świeży .htaccess, ponieważ IThemes utworzył tam sporo wyjątków na adresy IP. Jak wcześniej mówiłem wyłączyłem IPGeoBlock, więc to zapewne hinduskie i inne tego typu adresy ip. Patrzę na logi z wczoraj i widzę mnóstwo errorów typu: An error happend on Fastcgi processing, fallback to CGI i An error happened during Fastcgi processing Według narzędzi stronę opóźnia wyłącznie TTFB. Wartość ta skacze, w ciągu ostatniej godziny widzę poprawę. Czy słusznie podejrzewam, że po ostatnim update coś mogli zwalić i teraz to odkręcają? Czy syfu nie złapałem, nie wiem. Jeżeli chodzi o mój komputer siedzę na linuxie, co do strony od zawsze jest zabezpieczona iThemes, a po samej stronie nie widzę niczego złośliwego. Usunąłem kilka niepotrzebnych wtyczek (jednak jakieś się znalazły :-)) chociaż wtyczki nie mają na to wpływu. Przed tym była znacząca poprawa, wydawało się, że prędkość wróciła ale niestety w tym momencie znowu ją coś przytyka. Ponownie TTFB. Podejrzewam, że to na pewno coś z serwerem, tym bardziej, że na stronie nic się nie zmieniło, od tamtego czasu. Chyba, że po usunięciu wtyczki GeoIPBlock strona jest non stop atakowana, ale nie wiem jak to sprawdzić i czy to może mieć aż tak wpływ na TTFB.

Cześć, widzę, że jest tutaj trochę ogarniętych osób, więc może znajdę odpowiedź na swoje pytanie. Strona w OVH oparta o WP na pakiecie Perso od kilku dni bardzo długo się ładuje, a w kokpicie na każdą akcje trzeba czekać do kilkunastu sekund. Wcześniej (od ponad roku) było wszytko w normie. Po ostatnich pracach technicznych z ich strony (25 lipca, czwartek gdzie strona nie działała 5h bez żadnego uprzedzenia oczywiście, Gravelines data center) dostałem w nocy wiadomość o przekroczeniu zasobów. Z tego co widziałem na grafie w panelu był rzeczywiście mega wzrost, ale krótki o ok. 3-4 nad ranem (dziwna pora). Podejrzewam, że to spowodowało ''ograniczenie'' prędkości mojej strony przez OVH na pewien czas (wybaczcie niefachowy język, nie jestem specjalistą w tych sprawach). Z tego co widzę w narzędziach mierzących prędkość np. pageinsight, przyczyną wolnego ładowania się jest wzrost TTFB. Z drugiej strony narzędzia typu GT Metrix pokazują natomiast wciąż ten sam wynik szybkości co wcześniej. Strona technicznie nie zmieniła się, jest to lekki blog z 1000 UU dziennie. Nie wiem co może być tego przyczyną i jak zmusić OVH żeby wrzucił stronę ponownie na właściwy 'tor'. Przed zdarzeniem korzystałem z wtyczki GeoIP block, i miałem zablokowane adresy np. z Indii itd. żeby nie dostawać monitów, postanowiłem ją całkowicie wyłączyć kilka dni temu, ponieważ blokowała niektórych użytkowników z PL, a podobno i tak nie chroni to przed atakami. Może po prostu serwery OVH nie dają rady? To przecież serwer współdzielony... Dziękuję za pomoc!