[Problem z zapisaniem .htaccess na Linuxie]

2 godziny temu, Piotr GRD napisał:

 

Nie. To nie znaczy, że plik jest niewidoczny. Taki błąd najczęściej oznacza błąd składni w .htaccess (lub zawarcie w nim niedozwolonej komendy).

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.

[Problem z zapisaniem .htaccess na Linuxie]

25 minut temu, Borian napisał:

Czym się objawia ten brak możliwości zapisania? Nigdy się nie spotkałem żebym nie mógł zapisać pliku htaccess. Takie głupie pytanie: może po prostu robisz to z poziomu użytkownika a właścicielem pliku jest np. www-data i nie masz uprawnień? .htaccess to nie jest rozszerzenie tylko zwykły plik.

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..

[Problem z zapisaniem .htaccess na Linuxie]

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:

[Leverage browser caching - jak rozwiązać problem]

Dnia 2.08.2019 o 19:39, devopsiarz napisał:

 

Żadna ze znanych mi wtyczek cache, w tym LiteSpeed, mówię o wersjach darmowych, nie robi cache porządnie. Jeśli webserver jest niestandardowy (patrz: nie apache), to robią "biedacache" - wygenerowane pliki statyczne są serwerowane przez... PHP. Nie wiem jak na apache jest, mogę podejrzewać, że też źle. Czyli zamiast serwować bezpośrednio pliki, serwer podaje request do php, a php dopiero "kuma", że ma cache (redis czy coś tym stylu lub właśnie pliki statyczne).

 

Owszem w stosunku do "gołego" WP, te wtyczki przyspieszają działanie strony, ale i tak jest to marnowanie zasobów na wysokim poziomie i zmarnowany potencjał. Jeśli cache ma być porządny, to bez grzebactwa w webserverze się nie obejdzie i/lub współpracy z czymś z rodzaju varnish. Także nie polecam wydawać pieniędzy na te wtyczki, bo to nie jest warte świeczki.

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?

[Opinie o OVH]

Dnia 2.08.2019 o 13:14, Przemek Jagielski napisał:

http://travaux.ovh.net/?do=details&id=39513&PHPSESSID=1712f93ccd30a37b772af0da501ca1fb

Nie wiem na ile prace mogłyby być związane z Twoim konkretnie przypadkiem, ale w jakimś stopniu mogło to Ciebie też dotyczyć.

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

[Leverage browser caching - jak rozwiązać problem]

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.

[Opinie o OVH]

5 godzin temu, Pawel_15 napisał:

Pod takie małe strony hobbystyczne oparte na czymś lekkim takie hostingi jak OVH zazwyczaj się sprawdzają.

Pod bardziej zaawansowane rozwiązania bierze się w innych firmach (nie w masówkach) za trochę większe pieniądze.

Pod biznes bierze się już naprawdę mocny hosting albo VPS czy dedyka jeżeli zachodzi taka potrzeba.

 

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

[Opinie o OVH]

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?

[Strona wielojęzyczna]

24 minuty temu, darekm napisał:

chcesz tlumaczyc  automatem i to wrzucać    jako tekst  na stronę ?  do wp polecam  plugin WPML

 

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.

[Opinie o OVH]

20 minut temu, sempre napisał:

 

Na początku zobacz czy to na pewno wina szablonu i wtyczek a nie serwera, postaw czystego wordpressa i wykonaj testy, sprawdź TTFB, jeżeli będzie niskie wina leży po stronie niezoptymalizowanego szablonu i wtyczek, jeżeli wysokie to przenieś się na coś z większymi zasobami.

 

Pobierz sobie https://wordpress.org/plugins/wpperformancetester/ albo coś podobnego do sprawdzania obciążenia wtyczek, wychwyć które elementy szablonu/wtyczki powodują długi TTFB i się tego pozbądź/zoptymalizuj/zmień wtyczkę. Gotowych wtyczek typu wp rocket zdecydowanie nie polecam.

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.

[Strona wielojęzyczna]

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?

[Opinie o OVH]

41 minut temu, Przemek Jagielski napisał:

Rozumiem, że wersja PHP powyżej 5.6, zbędnych wtyczek nie ma, żadnego syfu nie złapałeś itp.?

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.

[Opinie o OVH]

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!