Содржина Маркетинг

Правилата за WordPress .htaccess имаат и исклучоци

WordPress направи голем еволутивен чекор напред во платформата за блогирање, приближувајќи го до полноправниот систем за управување со содржини со следење на ревизии, поголема поддршка за сопствени менија и - најинтригантната одлика за мене - поддршка на повеќе страници со мапирање на домени.

Ако не сте зависник од системот за управување со содржина, во ред е. Можете да го прескокнете веднаш покрај овој напис. Но, за моите колеги техно-гикови, код-глави и апачи-даблери, сакам да споделам нешто интересно и нешто кул.

Мулти-страница е функција која ви овозможува да стартувате било кој број веб-локации на WordPress со една инсталација на WordPress. Ако администрирате повеќе локации, убаво е затоа што можете да инсталирате одобрена група теми и графички контроли и да ги активирате за локациите на вашите клиенти. Постојат неколку технички пречки за мапирање на вашите домени, но процесот не е тежок.

Една од проблематичните области што ги идентификував е прилагодувањето на темата. Со оглед на тоа што темите можат да бидат достапни на повеќе веб-локации, сите прилагодувања што ги правите на темата ќе влијае и на сите други локации што ја користат таа тема на вашата инсталација на повеќе локации. Мојот начин околу ова е да дупликам тема пред да почнам да ја прилагодувам и јасно да ја именувам темата за клиентската страница за која ја стилизирам.

Друго интересно прашање е што се случува во . Htaccess датотека на вашиот Apache-сервер. WordPress треба да ги препишува патеките на основа блог по блог и тоа го прави со правило за препишување и PHP датотека.

WordPress го користи следново правило за препишување:

RewriteRule ^([_0-9a-zA-Z-]+/)?files/(.+) wp-includes/ms-files.php?file=$2 [L]

Разбиено, ова значи:

  1. RewriteRule – Оваа директива му кажува на Apache дека ова е правило за препишување.
  2. ^([_0-9a-zA-Z-]+/)? - Ова е редовен израз (RegEx) што одговара на низа знаци што започнува со изборна низа од алфанумерички знаци и цртички проследени со коса црта. Заградите означуваат група за снимање, што значи дека совпаднатиот текст може да се користи во стрингот за замена.
  3. files/ – Ова се совпаѓа со низата „датотеки/“.
  4. (.+) – Ова е уште една група за снимање што одговара на која било низа знаци, еден или повеќе пати.
  5. wp-includes/ms-files.php?file=$2 – Ова е стрингот за замена што ја заменува усогласената низа. Му кажува на Apache да го пренасочи барањето на „wp-includes/ms-files.php“, со вредноста на втората група за снимање ($2) како параметар за барање наречен „датотека“.
  6. [L] – Ова е знаменце што му кажува на Apache да престане да ги обработува сите дополнителни правила доколку ова правило се совпаѓа.

Во суштина, сè што е во поддиректориум на mysite.com/files/directory се препишува на mysite.com/files/wp-includes/myblogfolderpath… и тука станува интересно. Што ќе се случи ако навистина треба да имате датотека на вашиот сервер што е mysite.com/files/myfolder/myimage.jpg? Добивате грешка 404, тоа се случува. Правилото за препишување на Apache започнува и ја менува патеката.

Додуша, можеби никогаш нема да наидете на овој проблем, но јас го сторив тоа. Имав страница што требаше да користи додаток на JavaScript од друга веб-страница и требаше да најде графика на mysite.com/files/Images/myfile. Бидејќи немаше начин да ја сменам датотеката на страницата домаќин, ми требаше да пронајдам начин да го сторам тоа на мојот сервер. Лесното решение е да креирате состојба за препишување што прави исклучок за специфични датотеки.

Еве го решението:

RewriteCond %{REQUEST_URI} !/?files/Image/file1.jpg$
RewriteCond %{REQUEST_URI} !/?files/Image/file2.jpg$
RewriteRule ^([_0-9a-zA-Z-]+/)?files/(.+) wp-includes/ms-files.php?file=$2 [L]

Расчленети:

Линија 1:

  1. RewriteCond – Оваа директива му кажува на Apache дека ова е правило RewriteCond.
  2. %{REQUEST_URI} – Ова е променлива на серверот што ја содржи патеката на бараниот URI.
  3. ! – Ова е негациски оператор што значи „не“. Се користи за превртување на состојбата.
  4. /?files/Image/file1.jpg$ – Ова е редовен израз што се совпаѓа со точната низа „/files/Image/file1.jpg“ на крајот од бараниот URI. Прашалникот и коса црта напред пред „датотеки“ ја прават главната коса црта изборна.

Линија 2:

  1. RewriteCond – Оваа директива му кажува на Apache дека ова е правило RewriteCond.
  2. %{REQUEST_URI} – Ова е променлива на серверот што ја содржи патеката на бараниот URI.
  3. ! – Ова е негациски оператор што значи „не“. Се користи за превртување на состојбата.
  4. /?files/Image/file2.jpg$ – Ова е редовен израз што се совпаѓа со точната низа „/files/Image/file2.jpg“ на крајот од бараниот URI. Прашалникот и коса црта напред пред „датотеки“ ја прават главната коса црта изборна.

Линија 3:

  1. RewriteRule – Оваа директива му кажува на Apache дека ова е правило за препишување.
  2. ^([_0-9a-zA-Z-]+/)? – Ова е редовен израз што се совпаѓа со низа знаци што започнува со изборна низа од алфанумерички знаци и цртички проследени со коса цртичка. Заградите означуваат група за снимање, што значи дека совпаднатиот текст може да се користи во стрингот за замена.
  3. files/ – Ова се совпаѓа со низата „датотеки/“.
  4. (.+) – Ова е уште една група за снимање што одговара на која било низа знаци, еден или повеќе пати.
  5. wp-includes/ms-files.php?file=$2 – Ова е стрингот за замена што ја заменува усогласената низа. Му кажува на Apache да го пренасочи барањето на „wp-includes/ms-files.php“, со вредноста на втората група за снимање ($2) како параметар за барање наречен „датотека“.
  6. [L] – Ова е знаменце што му кажува на Apache да престане да ги обработува сите дополнителни правила доколку ова правило се совпаѓа.

Условите за препишување треба да бидат поставени пред правилото за препишување, во спротивно овој трик нема да успее. Треба да биде лесно да се измени оваа состојба за ваши сопствени цели, доколку наидете на сличен проблем. Решението функционираше одлично за мене, дозволувајќи ми да заменам прилагодена графика наместо помалку посакуваниот алт-текст што не одговара на мојот дизајн. Се надевам дека ќе работи и за вас.

Тим Пјаца

Тим Пјаца е партнер со Social LIfe Marketing и основач на ProSocialTools.com, ресурс за мал бизнис за допирање на локални клиенти со социјалните медиуми и мобилниот маркетинг. Кога не создава иновативни решенија кои ги забрзуваат деловните процеси, Тим сака да свири на мандолина и да изработува мебел.

поврзани написи

Вратете се на почетокот копче
Затвори

Откриен е блок за рекламирање

Martech Zone може да ви ја обезбеди оваа содржина без трошоци бидејќи ја монетизираме нашата страница преку приходи од реклами, врски со партнери и спонзорства. Ќе ни биде благодарно ако го отстраните вашиот блокатор на реклами додека ја гледате нашата страница.