У вас есть две проблемы здесь:
ваше правило переписать /application/views/... в /views/... является после правило, что переписывает все, к index.php. Вам нужно поставить более конкретную переписку до более общую переписку, чтобы предотвратить более общий из-за прекращения обработки.
Ваше правило перезаписи является неполным. У вас есть правило, чтобы запросы /application/views/... были переписаны так, как если бы файлы были фактически на /views/.... Тем не менее, , поскольку вы по-прежнему фактически сохраняете файлы в папке application/views/, вам не хватает правила, которое позволяет получить к ним доступ , как если бы они находились на /views/....
Здесь вы можете сделать правила перезаписи, чтобы заставить его работать. (Я ушел из правила, которое перенаправляет /application/views/... к /views/..., потому что я не понимаю, почему вам это нужно. - просто сделать /application недоступными и использовать только /views/... и тогда он не будет иметь значения, так или иначе)
RewriteEngine on
# Installation directory
RewriteBase/
# Protect hidden files from being viewed
<Files .*>
Order Deny,Allow
Deny From All
</Files>
# Pretend that views are one directory above where they actually are
RewriteRule ^views/(.*) application/views/$1 [L]
# Protect application and system files from being viewed,
# UNLESS we are redirecting to them from another rule
RewriteCond %{ENV:REDIRECT_STATUS} ^$
RewriteRule ^(?:application|modules|system)\b - [F,L]
# Allow any files or directories that exist to be displayed directly
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
# Rewrite all other URLs to index.php/URL
RewriteRule .* index.php [PT]
(благодаря @ ответ CDuv на mod_rewrite: allow redirect but prevent direct access для ENV:REDIRECT_STATUS трюка.)
на самом деле, вы можете обнаружить, что это имеет смысл для создания маршрута к этому контенту. Это связано с тем, что он позволяет перемещать каталоги application, modules и system из корня веб-сайта. Одно из преимуществ этого заключается в том, что вы можете делиться modules и system между несколькими приложениями Kohana, если вы когда-либо разрабатываете еще один. Другим является то, что это означает, что вам не нужно полагаться на htaccess для защиты доступа к этим каталогам.
Вот простой способ, который вы можете использовать для обслуживания этих файлов на основе модуля Kohana Userguide.
Добавить этот маршрут в bootstrap.php:
// Static file serving (CSS, JS, images) - ADD MORE EXTENSIONS IF NEEDED
Route::set('media', 'views(/<file>)', array('file' => '.+\.(css|js|jpg|png)'))
->defaults(array(
'controller' => 'media',
'action' => 'media',
'file' => NULL,
));
Добавить контроллер Controller_Media:
class Controller_Media extends Controller
{
public function action_media()
{
// Get the file path from the request
$file = $this->request->param('file');
// Find the file extension
$ext = pathinfo($file, PATHINFO_EXTENSION);
// Remove the extension from the filename
$file = substr($file, 0, -(strlen($ext) + 1));
if ($file = Kohana::find_file('views', $file, $ext))
{
// Check if the browser sent an "if-none-match: <etag>" header, and tell if the file hasn't changed
$this->check_cache(sha1($this->request->uri()).filemtime($file));
// Send the file content as the response
$this->response->body(file_get_contents($file));
// Set the proper headers to allow caching
$this->response->headers('content-type', File::mime_by_ext($ext));
$this->response->headers('last-modified', date('r', filemtime($file)));
}
else
{
// Return a 404 status
$this->response->status(404);
}
}
}