http___blog.superhosting.bg_tips-of-support-htaccess-document-root.html_2.xml
http___snewscms.com_forum_index.php_topic_7570.0.html.xml
1.1 2.1 2.2 2.3 2.4 2.5 2.6 2.7 3.1 4.1 4.2 4.3 4.4 5.1 5.2 5.3 6.1 7.1 8.1 9.1 10.1 11.1 12.1 12.2 12.3 12.4 12.5 13.1 13.2 13.3 13.4 13.5 14.1 15.1 15.2 15.3 16.1 16.2 16.3 16.4 16.5 17.1 18.1 19.1 20.1 21.1 22.1 23.1 26.1 27.1 28.1 29.1 29.2 30.1 31.1 32.1 33.1 34.1 35.1 37.1 38.1 39.1 40.1 41.1 42.1 43.1 44.1 45.1 46.1 47.1 48.1 49.1 50.1 51.1 52.1 53.1 54.1 55.1 56.1 57.1 58.1 59.1 60.1 61.1 61.2 62.1 63.1 64.1 65.1 66.1 67.1 68.1 69.1 70.1 71.1 72.1 73.1 74.1 75.1 76.1 77.1 78.1 78.2 78.3 78.4 79.1 80.1 81.1 81.2 82.1 83.1 84.1
Хитрини с .htaccess файла – част 1 Дойде ред на новата „порция“ от нашите „Съвети от support- a“. Както вече знаете, целта на тази категория е да получавате професионално мнение и полезна информация от вашата хостинг компания СуперХостинг.БГ. Не малко са въпросите ви за .htaccess файла. По тази тема има много какво да се каже... Вече е факт първата от поредицата публикации, в които колегите ще споделят интересни решения и казуси, с които се сблъскват ежедневно. Надяваме се така да ви помогнем в опознаването на възможностите, които дава .htaccess файла. Споделяйте и вие интересни моменти от вашата практика! В следващите редове нашия колега Алекс от отдел Техническа поддръжка посочва каква настройка е необходима и какво трябва да съобразите, така че основният домейн в акаунта ви да зарежда съдържание от друга, желана от вас поддиректория. На нашите сървъри за споделен хостинг като глобална настройка е зададено, основния домейн на всеки акаунт да зарежда съдържание от /public_html директория - основна директория (Document Root). След голямото увеличение на Add On домейните, клиентите ни питат как да променят основната директория за конкретния акаунт, без това да променя URL адреса, на който се достъпва сайта. Тъй като това е настройка, зададена в конфигурацията на самия сървър, не е удачно да бъде променяна само за дадения акаунт. В този случай, с колегите съдействаме да се извършат желаните промени на ниво акаунт чрез Rewrite правилата в .htaccess файла. Пример за подобна ситуация е, когато в даден хостинг акаунт има добавени голям брой Add-On домейни. По подразбиране отделните Add-On домейни се създават с Document Root - поддиректория на /public_html. Клиента желае и основния домейн да зарежда съдържание на поддиректория на /public_html за по-лесно управление на файловете в акаунта. Чрез добавяне на следните няколко реда в .htaccess файла, разположен в /public_html, вашият сайт ще зарежда съдържание от желаната поддиректория на /public_html, без това да променя URL адреса: * domainname – името на вашия домейн; * tld – домейн от първо ниво (Top Level Domain) - .com, .bg, .eu, .net, .org ...; * directoryname – името на желаната поддиректория на /public_html; По този начин, достъпвайки вашия домейн с или без www отпред, ще се зарежда съдържанието, което сте разположили в /directoryname. Трябва да се вземат предвид следните 2 особености относно действието на .htaccess файла: Аpache уеб сървърът обхожда рекурсивно директориите за .htaccess файлове и те влияят на цялото дърво от поддиректории. Поради тази причина са възможни конфликти между Rewrite правилата, описани в .htaccess файлове, разположени в директории и техните поддиректории. Обикновено при еднакви системи или когато няма специфични правила, това не създава проблеми. Въпреки това, трябва да го имате предвид в случаи на некоректно сработване на други директиви. Добра практика е поставянето на .htaccess файлове със съответните правила в папки, намиращи се на едно и също ниво. Някои системи използват глобално зададената на сървъра основна директория за тяхната работа. С посочените по-горе правила се променя само директорията, от която зарежда съдържание вашето уеб приложение. Глобално зададената на сървъра Document Root, остава непроменена: /home/accountname/public_html. Поради тази причина, е необходимо да съобразите начина на работа на софтуера, който използвате във вашия сайт, за да избегнете възможни конфликти. Проверка за настройки в сървъра можете да направите чрез файл с разширение .php (например: p.php), в който въвеждате следното: *accountname - името на вашия акаунт; Чрез този .php файл се визуализират глобалните настройки на сървъра, както и локално извършените в собствения php.ini файл, който по подразбиране се намира в основната директория на вашия акаунт. В секцията PHP Variables, за _SERVER["DOCUMENT_ROOT"], можете да видите зададената на сървъра основна уеб директория. Тази променлива, може да променя стойността си, например за Add-On домейн, тъй като за него вие имате възможност да посочвате Document Root. Ще се радваме да споделите като коментар под тази публикация интересни случаи и от вашата практика! Имали ли сте подобни казуси и причини, поради които сте желали смяна на основната директория, от която се зарежда вашия сайт? За какви други особени ситуации, директиви или действия на .htaccess файла искате да научите повече? Питайте! А ние ще ви отговорим и ще предоставим информацията, от която имате нужда? Не пропускайте да се абонирате за нашия блог и да следите нашата фен страница във Facebook, защото сме ви приготвили още много интересна и полезна информация! Добавяне на воден знак към снимки с помощта на .htaccess RewriteEngine On RewriteCond %{REQUEST_FILENAME} -f RewriteRule \.(gif|jpeg|jpg|png)$ /път-до-файла/watermark.php [QSA,NC] Интересно е какво следва да съдържа watermark.php google.com knows everything. http://www.sitepoint.com/watermark-images-php/ Тази серия от съвети ми харесва все повече с всяка нова тема. Ето и нещо полезно: Лесно поставяне на сайт във временен режим “поддръжка/ремонт” чрез преименуване на файл с име maintenance-off на maintenance-on. Позволява се публичен дустъп само на определен(и) IP адрес(и) “888.888.888.888″. Форматираната HTML страница (index.html) за този сервизен режим на сайта е в поддиректория “maintenance”. Всичко е от гледна точка на public_html директорията. RewriteEngine On RewriteBase / RewriteCond %{HTTP_HOST} ^mydomain.com [NC] RewriteRule ^(.*)$ http://www.mydomain.com$1 [L,R=301] RewriteCond %{DOCUMENT_ROOT}/maintenance-on -f RewriteRule !^maintenance/.*$ /maintenance/ [R,L] Пренасочване на http://www.sitename.com към sitename.com основно заради СЕО причини: RewriteEngine On RewriteCond %{HTTP_HOST} !^your-site.com$ [NC] RewriteRule ^(.*)$ http://your-site.com/$1 [L,R=301] Блокиране на “хотлинкинг“ или още известно като “Стига си ми крал трафика, твойта кожа…“ RewriteEngine On #Replace ?mysite\.com/ with your blog url RewriteCond %{HTTP_REFERER} !^http://(.+\.)?mysite\.com/ [NC] RewriteCond %{HTTP_REFERER} !^$ #Replace /images/nohotlink.jpg with your “don’t hotlink” image url RewriteRule .*\.(jpe?g|gif|bmp|png)$ /images/nohotlink.jpg [L] Къстъм страници за грешки: ErrorDocument 400 /errors/badrequest.html ErrorDocument 401 /errors/authreqd.html ErrorDocument 403 /errors/forbid.html ErrorDocument 404 /errors/notfound.html ErrorDocument 500 /errors/serverr.html Премахване на файлови окончания от URL: RewriteEngine on RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_FILENAME}\.html -f RewriteRule ^(.*)$ $1.html # Replace html with your file extension, eg: php, htm, asp Нещо бая важно и полезно: компресиране на файловете, преди да бъдат изпратени към браузъра. Намалява значително трафика, особено ако има много код: AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/javascript text/css application/x-javascript BrowserMatch ^Mozilla/4 gzip-only-text/html BrowserMatch ^Mozilla/4.0[678] no-gzip BrowserMatch bMSIE !no-gzip !gzip-only-text/html Хайде със здраве и дано съм ви бил полезен. Ще се радвам за повече инфо как ефикасно да блокираме Китайския и Украински спам народ през .htaccess Нещо много полезно за силно натоварени сайтове е добавянето на CDN – Content Delivery Network – това е отделен адрес, който предоставя съдържание, което рядко се променя, като този сървър има специфични настройки… В моя случай имам форум с доста посещения… в CDN съм изнесъл аватарите, снимките и всякакви други картинки, CSS и JS файлове, които на практика се променят доста рядко. За целта се създава отделен поддомейн в основния домейн на сайта. На този поддомейн в корена се поставя следния .htaccess файл: Header unset Pragma FileETag None Header unset ETag Header set Cache-Control “public, no-transform” Header unset Last-Modified ExpiresActive On ExpiresDefault “access plus 1 day” Това ще накара браузърите да кешират съдържанието за поне 24 часа. В моя случай това намали трафика на сървъра от 8GB на 6GB, което се е 25% надолу. Освен това cookies на основния домейн са настроени да не са валидни за всички поддомейни. По този начин при зареждането на картинки, CSS и JS файлове не се разменят cookies със сървъра, което също пести доста ресурс, когато има постоянно стартирани сесии… Ако имате проблем с това, че ви трябват cookies за всички поддомейни, купувате още един основен домейн, правите го на addon в хостинг панела и качвате на него CDN-а… така вече cookies няма да ходят на CDN-а, дори и да са валидни за всички поддомейни. И за да работи всичко лесно и безпроблемно с повечето open source и безплатни системи може да се направят soft-links на сървъра, така че да се свържат различни домейни на сървъра с една и съща директория… Може би това е една нелоша тема за следваща хитрина от съпорта ngnix-а е много добро решение за static content. Не само защото е по-лек от apache, има куп предимства сред, които е и решение на C10k проблема. Много полезна информация, особено за сайтове които имат проблеми с натоварването, благодаря! Оставете коментар Все още няма връзки за обратно следене.
1.1 1.2 3.1 4.1 5.1 6.1 7.1 8.1 9.1 10.1 12.1 12.2 13.1 14.1 14.2 14.3 15.1 16.1 17.1 18.1 19.1
I am not an expert either. However, logic and common sense, usual is my salvation(amen) It seems we both have different server configurations. I adjusted your code, (which is by the way, far better then the code I've tried earlier today) to this: RewriteEngine On #RewriteBase /sNews16 RewriteCond %{REQUEST_FILENAME} -f RewriteRule ^(.+) $1 [L] RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.+)/$ index.php?category=$1 [L]RewriteCond %{REQUEST_FILENAME} !-d I needed the extra line, to prevent .htaccess from adding an extra slash. The red line tells the server only to add slashes if it is not a directory. I've tested yours and mine like this: I've created a testmap, containing an index.html and somefile.html. I also have a somefile.html in the same directory as snews. That way, I am able to test all kinds of request like: testmap/ testmap testmap/somefile.html somefile.html Maybe you can do some similar testing on your local install?