15
I recommend trying out the Patrol plugin. It avoids .htaccess headbanging and just handles the redirects via PHP.
Patrol Plugin for Craft CMS
In the Settings, turn on Secure Connections and add a backslash / to the Protected Areas settings box. That will force SSL across the board. If you want to get more specific, you can provide multiple, more-...
15
For reference, this worked:
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{SERVER_NAME}%{REQUEST_URI} [R,L]
9
Craft works by taking requests that normally would 404—because they don't actually exist on the server but in the database. The piece that makes this happen is the rewrite rules.
It's helpful to look at Craft's .htaccess file line-by-line:
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
The request must not already exist and the ...
9
Because files that start with a . are considered "hidden" by many file systems (specifically OSX default).
If the file is hidden, then there's a good chance that the user won't know about it, and won't be able to FTP it to the server. It's better for the file to be intentionally misnamed, rather than accidentally hidden.
8
This worked for me on the Arcustech server:
Put this code in the root .htaccess file:
<IfModule mod_rewrite.c>
RewriteEngine On
# Send would-be 404 requests to Craft
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !^/(favicon\.ico|apple-touch-icon.*\.png)$ [NC]
RewriteRule (.+) index.php?p=$1 [QSA,L]...
7
Taken from this answer on Stack Overflow:
.htaccess mod_rewrite: rewriting querystring to path
<IfModule mod_rewrite.c>
RewriteEngine On
# Remove index.php
RewriteCond %{THE_REQUEST} ^GET.*index\.php [NC]
RewriteCond %{REQUEST_URI} !^/index\.php/admin\b [NC] # Don't mess with admin requests
RewriteRule (.*?)index\.php/*(.*) /$1$2 ...
5
It's not so much that you can't have the index.php file in a subfolder that might be an issue; it is that you can't put the craft folder above your webroot. If you have access to the folder that htdocs is inside, you should try putting the craft folder inside that. It might not be obvious, but there's no reason that the public folder has to be named public. ...
5
Try this sample htaccess-file I'm using on another site.
RewriteEngine On
RewriteBase /
# If the request is not secure
RewriteCond %{HTTPS} off
# Redirect to the secure version
RewriteRule (.*) https://%{HTTP_HOST}/$1 [R=301,L]
# Normal redirect rules
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /index.php/$1 [...
5
As another option that I usually do in addition to .htaccess, is to also add this to the array in craft/config/general.php file, and it'll stop Craft from ever adding the index.php.
'omitScriptNameInUrls' => true
Doing it this way prevents Craft from ever adding in the index.php to redirects, I believe.
5
Been using this one for years, works great:
<IfModule mod_rewrite.c>
RewriteEngine On
# ========================================= #
# Force website to use "www"
RewriteCond %{HTTP_HOST} ^example.com [NC]
RewriteRule ^(.*)$ http://www.example.com/$1 [L,R=301]
# ========================================= #
# =================...
5
It turned out that the problem was from customizing the domain's document root in the userdata files and then the PHP-FPM configuration had not been rebuilt and the service not restarted. The following resolved the issue:
/scripts/php_fpm_config --rebuild
/scripts/restartsrv_apache_php_fpm
It's interesting since there are a broad variety of issue that ...
4
Providing you have the necessary permissions to do this, the following in your .htaccess should do the job:
RewriteCond %{HTTP_HOST} !^domain\.co\.uk$ [NC]
RewriteRule ^(.*)$ http://domain.co.uk/$1 [R=301,L]
In place, the full file will probably look something like this:
<IfModule mod_rewrite.c>
RewriteEngine On
# Redirect to non-www domain
...
4
.htaccess should always be faster because it doesn't involve PHP or Craft at all.
But on top of that the {% redirect %} tag should be pretty darn quick.
Upon hitting it, Craft immediately calls Yii's CHttpRequest->redirect(), which sets the redirect header and terminates the current request.
4
The condition should be:
RewriteCond %{HTTPS} !=on
(You were missing the = sign.)
For more info, see our help article, How do I force SSL for CP requests?
4
This came up in the Craft Slack not so long ago. You'd want something like this...
# ------------------------------------------------------------
# Remove index.php
# ------------------------------------------------------------
RewriteCond %{THE_REQUEST} ^GET.*index\.php [NC]
RewriteCond %{REQUEST_URI} !^/index\.php/admin\b [NC] # Don't mess with admin ...
4
This question comes close but implementing with a subdomain doesn't work.
It should work as long as you modify the rewrite rule to account for the subdomain:
RewriteCond %{HTTP_HOST} !^foo\.bar\.com$ [NC]
RewriteRule ^(.*)$ http://foo.bar.com/$1 [R=301,L]
The code you posted was missing the ^ before foo\.bar\.com on the RewriteCond line. The purpose of ...
4
You can alter the index.php file and add [set_time_limit][1](300); anywhere below the <?php tag.
You can also try to set it by ini_set('max_execution_time', 300);
For the reason why it returns a 500 Internal Server Error, the server does not support the php_value and php_flag parameters through the htaccess file or it doesnt use the php5 module. You ...
4
In this case, the Apache mod_rewrite module wasn't installed, so the <IfModule mod_rewrite.c> block of Craft's default .htaccess file was being skipped not allowing index.php to be rewritten in the URL.
3
If I understand this correctly, you can't put the /craft folder above the public root, so you put both /craft and /public inside public root? That's no point, and you need a lot more .htaccess vodoo to get that sorted out. But, if the craft folder has to stay inside the public webroot, you should just move it there, and not have an additional /public folder ...
3
Only setting headers in .htaccess doesn't fix the problem.
As Marion Newlevant points out in her answer the cross domain works with the headers set. But you still get a white page as a preview.
Looking further into the problem, I've found that the page tries to do a post request to the other domain.
It calls upon the action function actionPreviewEntry() in ...
3
If you're looking to only allow certain IP addresses to access the entire control panel, you're best bet would be to whitelist them via an .htaccess file.
Something like:
<Limit GET POST>
order deny,allow
deny from all
allow from 1.2.3.4
</Limit>
If you're looking to just allow certain Craft-specific actions by IP address, then you'...
3
Storing the cookie
I'd recommend using the LJ Cookies plugin...
{% do craft.lj_cookies.set('locale', craft.locale, '', '/' ) %}
Retrieving the cookie
The LJ Cookies plugin is also capable of reading cookies, so you could simply put a conditional redirect at the top of your layout...
{% set currentLocale = craft.locale %}
{% set goToLocale = craft....
3
The second one will force SSL no matter which page you're on, including any control panel requests, which is what you're after. As mentioned in the docs, make sure that goes above Craft's default rewrite code.
The only other thing you'll want to do is change the site URL in Craft itself; you can do that in Settings -> General so Craft knows to spit out ...
3
You could set up your assets through Amazon S3 or another remote service then that wouldn't be a problem.
Alternatively you will need to download all the assets locally if you have relative paths /uploads/images/banners/banner1.jpg.
Though maybe another option is to set the path to include the domain then you can probably get the files from the server (so ...
3
If it's just a simple redirect, it'll be quicker to do it in .htaccess and not invoke PHP/Craft at all.
3
This is indeed possible. You'll want to update your route to point to an array with and identify your controller path with the key action:
public function registerCpRoutes()
{
return array(
'pluginname/edit' => array('action' => 'pluginName/editItem'),
);
}
In your plugin controller, you can create any number of variables you need and hand ...
3
Wordpress’ .htaccess file and Craft’s .htaccess file both use the same strategy: If the request is not pointing to a valid file or folder, rather than have Apache respond with a 404, re-route the request to index.php.
It sounds to me like you’ve got a .htaccess fie at your web root which is handling Wordpress’ index.php redirect, and that is taking ...
3
Have you checked the path of the asset source the image is in? Sounds like that might still be the old server's path.
Best practice is to use Environment-specific variables in your config file, and then use those in you Asset Source settings as well.
So, use {basePath}assets/site as your File System Path for instance (if you've used basePath as a config ...
3
Those are the 2 thing you need to ensure are correct.
If .htaccess files are being ignored, you need to check to see that AllowOverride is set correctly. See http://httpd.apache.org/docs/2.4/mod/core.html#allowoverride for details on setting "AllowOverride All". You need to also ensure that it is set in the correct scope - ie, in the right block in your ...
3
I have Craft public files set up within subdirectories of a primary domain’s web root.
The following .htaccess rules allow for the public_html subdirectory to act as the new web root.
Is there a reason you're doing it this way? The .htaccess you have is only rewriting the content, it's not actually setting the web root. You're basically asking Apache to ...
Only top voted, non community-wiki answers of a minimum length are eligible
