20
The issue here is that your Redirect directive is conflicting with Craft’s index.php-hiding RewriteRule directive. (Redirect is a mod_alias directive and RewriteRule is a mod_rewrite directive. They’re two separate modules that can be used for the same thing, but lead to unexpected consequences when used together.)
To fix this, use a RewriteRule directive ...
14
You can use the HttpRequestService:
craft()->request->redirect($myAwesomeUrl);
12
If you are trying to cover the site from the public while working on it live, i personally would name my coming soon template file 503.html
Then in the General Settings section of the control panel, switch System Status off.
That way so long as you are logged in, you can access the site as normal but anyone else visiting your site will see the contents of ...
11
As Brad said the new default behavior is for users to be redirected wherever postLoginRedirect is set to (if a redirect param was not in the POST data).
You can get your old behavior back by adding that hidden redirect param though, set to craft.request.getPath():
<input type="hidden" name="redirect" value="{{ craft.request.path }}">
11
First – your Twig syntax is a little off. Here's how you could add the current URL/request path to a link, as a query parameter p:
<a href="members/login?p={{ craft.request.path }}">Log in</a>
Notice that the syntax/tag for printing a value/variable is {{ value }}, not {% value %}.
Second, since the redirect in this case should happen when the ...
10
Take a look at Craft's redirect function:
{% redirect '/' %}
In your case it would look like this:
{% redirect 'neptune/' ~ id ~ '/confirm' %}
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 ...
8
You do not use the {{ }} inside other brackets you also should not use ' ' unless it is a specific string you want interpreted. Try instead:
{% for entry in craft.entries.section('services').limit(1) %}
{% redirect entry.url %}
{% endfor %}
And you should be good to go
7
You have twig syntax ({{...}}) inside twig syntax ({%...%}), which is never right. Does this work?
{% if entry.hasDescendants() %}
{% redirect entry.getChildren().first().url %}
{% endif %}
7
In Craft 3 we are looking at something similar to:
Craft::$app->getResponse()->redirect(UrlHelper::cpUrl('settings/plugins/craft-mailchimp'))->send();
7
There are a few plugins which can handle this, but Retour is the newest and shiniest!
https://github.com/nystudio107/retour
It's from the same developer as SEOmatic... he puts a lot of love & attention into his plugins, so you know it's safe to rely on.
6
One way you can avoid this is by making a small change to the htaccess rules for removing index.php from Craft URLs. You can remove the query string from RewriteRule (.+) index.php?p=$1 [QSA,L] and replace it with /$1
So the full set of rules to remove index.php would be
# Send would-be 404 requests to Craft
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %...
6
Craft has a twig redirect tag.
You should be able to create a "redirect" template that handles redirects based on {slug} and/or url segments and then use Craft routes to direct "legacy-subdirectory" requests to your redirect template. I have not tested this.
6
I think:
{% redirect "/visit/index?artwork="~workTitle %}
5
Here is what i have done. Not sure if it helps you. I can't add comments. So here you go. This is based on geo plugin
Plugin serviceclass:
//to get local ele
private function getLocalElement()
{
$source=craft()->request->getRequestUri();
if($source==''){
$source = 'home';
}
return craft()->elements->...
5
If you wanted to do this without having to write your own plugin, you can achieve this with a simple custom route and an extra parameter in your template.
Your hidden fields could look like:
<input type="hidden" name="action" value="entries/saveEntry">
<input type="hidden" name="redirect" value="schedule/{id}">
And then in config/routes.php ...
5
Update line 5 to concatenate the path/URL with the variable workTitle.
{% redirect "/visit/index?artwork=" ~ workTitle %}
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]
# ========================================= #
# =================...
4
Craft 2.2 introduced the postLoginRedirect config setting which affects not only where users on the front-end of the site get redirected to after logging in (defaults to the home page), but where they get sent if they visit the front-end login page while they are logged in.
4
If you want to "redirect" all parent entries of your structure that have child entries, you could do something like this in your navigation (untested code!):
<ul>
{% nav page in pages %}
<li>
{% if page.getChildren()|length %}
<a href="{{ page.getChildren().first().url }}">{{ page.title }}</a>
...
4
I agree with Bryan, personally I like to use the Browser-Update.org notification.
Nevertheless, if you want to use .htaccess just make sure you put your redirect code before Crafts routing:
<IfModule mod_rewrite.c>
RewriteEngine On
# Redirect old Browsers
RewriteCond %{HTTP_USER_AGENT} "MSIE [1-7]" [NC]
RewriteRule ^(.*)$ http://...
4
Although it is (as of today) not yet documented, looking through the redirect twig extension revealed that the redirect tag can accept a second parameter for the http status code. So forcing a 301 is done as follows:
{% redirect 'pricing' 301 %}
I've sent a request to P&T to add this to the docs.
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
I would suggest making the “admin” check a little more strict:
// Make sure this isn't a CP request
if (!isset($_GET['p']) || strncmp($_GET['p'], 'admin', 5) !== 0)
{
// ...
(Assuming you’re using the recommended .htaccess redirect rule, by the time the request hits index.php, the original request URI will be available as $_GET['p'].)
The Accept-...
4
The config settings you're looking for are probably 'activateAccountSuccessPath' and 'autoLoginAfterAccountActivation'.
4
You can use the redirect tag. Put this in your index.html template:
{% redirect "coming-soon" %}
EDIT
If you want to stay on the homepage but want to show the template code for another page, you can use Twig include. Put this in your index.html template:
{% include "coming-soon" %}
Alternatively, just put your Coming Soon template code straight onto ...
4
I found by just adding the code from the following site it will add slashes via a 301 redirect:
RewriteCond %{REQUEST_URI} /+[^\.]+$
RewriteRule ^(.+[^/])$ %{REQUEST_URI}/ [R=301,L]
Now my .htaccess file looks like the following:
<IfModule mod_rewrite.c>
RewriteEngine On
# 301 redirect with trailing slash
RewriteCond %{REQUEST_URI} /+[^\...
4
Craft has a config setting for this (for dynamic urls)
You can set it in your config file like so:
'addTrailingSlashesToUrls' => true
If someone links to the url via a non-trailing-slash pattern, it should redirect.
If you use an apache rewrite, you can exclude the craft admin by checking the uri pattern
RewriteCond %{REQUEST_URI} !(admin)$
...
4
You can either set the URL Format of the landing pages channel to {slug} (the same as your normal pages)
Or you could try putting the landing pages in the normal pages structure, but give them a new entry type so you can use different fields.
Only top voted, non community-wiki answers of a minimum length are eligible