I have in my module named 'categorie' a implementation of:
function categorie_url_inbound_alter(&$result, $path, $path_language) {
if ($path == 'e') {
$result = 'user';
}
}
I'm planning to do something a bit more advanced but I can't even seem to get the basic one working.
With this implementation I expect that if a user goes to mysite.com/e , he gets the user page. But I'm getting a 404.
In this topic:Using module: url_alter and it's hook: hook_url_outbound_alter() they also suggested you need to implement the hook_boot() with nothing in it. However I did implement this hook and this didn't change the behavior.
UPDATE:
I have the "Path" module installed from core and I declared some url aliases in the clean url section. (Maybe this gives a conflict?)
UPDATE2: cleaning the cache didn't do the trick either.
UPDATE3:
I also tries doing the url rewriting in the htaccess file. But when the url was rewritten it destroyed the theming. (https://drupal.stackexchange.com/questions/76475/drupal-does-rewrite-url-but-cant-load-css-themes/76493?noredirect=1#76493). So that's why I'm now trying to do it with the custom module.
What cache did you clear ? It probably not sufficient
to just clear the page cache. You can try a call to
drupal_lookup_path('wipe');
To clear the alias cache. This fixes many problems with the alias system.
Other things to check are the alias database table to be sure that the alias are being
set in the first place.
I'm not 100% sure, cause i'm also very new to drupal. But i think you need to implement hook_url_outbound_alter as well. Good luck. If i find a better answer i'll post it.
Cheers
Related
I need a way to log out all signed in customers from my Prestashop site, as a domain name migration caused some issues with user sessions, and having customers sign out and re-sign in is fixing it.
I tried the following code, to no avail:
$customers = Customer::getCustomers();
foreach($customers as $customer) {
$obj = new Customer($customer['id_customer']);
$obj->logout();
}
Is there a way to natively invalidate/destroy all user sessions from Prestashop (code or back office)? Otherwise, plain PHP methods are more than welcome.
What I ended up going for is pretty much what Mahdi Shad mentioned in his answer, but allow me to add more details:
I changed the prefix of Prestashop cookie names from "Prestashop-" to "MySiteName-" (you can change to whatever you want), by going to /classes/Cookie.php, and changing the following line (line 78):
$this->_name = 'MySiteName-'.md5(($this->_standalone ? '' : _PS_VERSION_).$name.$this->_domain);
Well, overriding the class instead of directly modifying it is surely a better practice though.
This change in cookie name immediately makes the old browser cookies obsolete (even if thet aren't expired), and thus all users get signed out. Exactly what I want!
You have to change the Prestashop cookie to avoid validating login.
It's impossible to change the "cookey-key" because of failing all passwords but you can override Cookie class and change cookie pattern.
I'm using typo3 and realurl.
In my extension I generate some ID's (next and previous page) and everything works fine up to this point. An example link looks like:
/index.php?id=12
The link takes the visitor to the specific page, but this link is in the url as well. Of course I generate this linke exactly like this:
$GLOBALS['TSFE']->baseURL . "index.php?id=" . $banner->getPrevious();
So, it is exactly what i expected. But how can i turn this url into a seo-friendly URL?
Is there something like $realUrl->createUrlFromId()? :P
I checked the manual, looked in some forums, but 99% of the time it is something related to TypoScript, which I don't need (from my point of view) in this case.
Edit:
Here is the .htaccess:
http://pastebin.com/DBXjLYjp
Thank you in advance
RealURL hooks into several core methods to generate links, and manipulates the result to be a speaking URL. So, no, it does not offer an own method, but extends existing ones.
You don't use a link generation, but build it by yourself. RealURL therefore can not access your link.
The htaccess only converts speaking urls back into GET-params.
Use a method like pi_linkToPage, a link viewhelper, or a TypoScript typolink to generate a link.
$myLink1 = $this->pi_linkToPage('example', 42);
$myLink2 = $this->cObj->typolink('example', array(
'parameter' => 42,
));
Background: had a working Wordpress 3.7 site at olddomain.com.
I moved it to newdomain.com successfully, and in the process added this to wp-config:
define('WP_HOME','http://newdomain.com');
define('WP_SITEURL','http://newdomain.com');
Now when I attempt to login from newdomain.com/wp-admin I'm getting the cross-browser error (despite having cookies enabled and clearing existing cookies):
ERROR: Cookies are blocked or not supported by // your browser.
You must enable cookies to use WordPress.
I tried going into wp-login.php and commenting out the following lines (744-747) to stop the conditional testcookie check
// If cookies are disabled we can't log in even with a valid user+pass
if ( isset($_POST['testcookie']) && empty($_COOKIE[TEST_COOKIE]) )
$user = new WP_Error('test_cookie', __("<strong>ERROR</strong>: Cookies are blocked or not supported by // your browser. You must <a href='http://www.google.com/cookies.html'>enable cookies</a> to use WordPress."));
else
$user = wp_signon('', $secure_cookie);
but doing that leaves me stuck in a redirect loop back to the admin page:
http://myapp.com/wp-login.php?redirect_to=http%3A%2F%2Fmyapp.com%2Fwp-admin%2F&reauth=1
Do I need to change (or not set) the site URL? or is there another potential way to troubleshoot this? thanks
add to wp-config.php
define('ADMIN_COOKIE_PATH', '/');
define('COOKIE_DOMAIN', '');
define('COOKIEPATH', '');
define('SITECOOKIEPATH', '');
original source http://wordpress.org/support/topic/cookie-error-site-not-letting-me-log-in
Having migrated hundreds of WP sites, here's a few thoughts :
If migrating the DB : Check the database options table (probably wp_options) column "option_name" that values "siteurl" and "home" have the correct "option_value" for your site. "siteurl" is huge.
I can testify that the options table tweak is the bare minimum required to migrate a DB to a new domain in WP. (will not cause redirection, will still have issues)
WP looks up these DB options to serialize the site to domain and I am pretty sure the defines are lower in the stack and of no help. Consider the wp-admin activities as loosely coupled to the front. You can break everything (done it) in the front and the admin will still function.
Also - did/does the site work with generic install/no migration or tweaks?
As mentioned - .htaccess (missing or misconfigured) will cause your error. Regarding the .htaccess file, if used, this is a dot.file and many operating systems will "ignore" or "make invisible" so a copy/paste or FTP application or similar may not carry the .htaccess
(pretty sure on this) If you moved the DB and used pretty urls, and missed the .htaccess that could be all you need to fix. I just tested locally on a sandbox install and the table wp_option column "option_name" value "permalink_structure" when left blank in column option_value will return to ?p=1 (non-permalink) status and .htaccess will be mostly bypassed.
This worked for me.
Remove //define('COOKIE_DOMAIN', 'www.domain.com');in your wp-config.php
Ensure that all the files have the ANSI format and not utf-8
This error also occurs when moving a multisite installation to a new domain if you update all options on the database table (usually wp_options), but forget to change the DOMAIN_CURRENT_SITE line on wp-config.php:
define( 'DOMAIN_CURRENT_SITE', 'yourdomain.com' );
I experienced this due to my caching plugin.
W3 Total Cache had added the following to my wp-config.php file:
define('COOKIE_DOMAIN', 'www.olddomain.com'); // Added by W3 Total Cache
Since it was hard coded, it didn't update to the new site domain. After deleting the added code (because I don't currently use the plugin), I was able to log in again.
I'd check wp-config.php for the word "cookie" to see if a plugin might have added something like this.
I was getting this same error.
I had hard coded the Home and SiteURL in wp-config.php for a brand new website - no plugins even installed.
The problem: I had a space at the end of the URL.
define('WP_HOME','http://100.000.000.01/~acctname/wp ');
define('WP_SITEURL','http://100.000.000.01/~acctname/wp ');
Removing the space fixed this error.
define('WP_HOME','http://100.000.000.01/~acctname/wp');
define('WP_SITEURL','http://100.000.000.01/~acctname/wp');
this bug was driving me crazy the last couple of days so i thought after fixing it to share with you guys! the problem was when i was trying to login into my wordpress backend i got this annoying cookies error so this is how i fixed it!
Go to your ftp and your domain.
Afterwards go to your wp-contents
Go to your themes folder
Chose the theme that is active
Look for functions.php of your teem and open it
At the ende of the code you should see closing tag p> just remove it clear the spaces also and save it!
Go to your domain.com/wp-login.php
and try to login it should be fixed afterwards you can put the tag back where it was and save it again that was the solution for me this trick also fixes the white page problem in wordpress
Cheers!
I have been googled & tried all ways to get rid of this cookie issue. Finally i found two solutions, which could help you.
Solution 1:
yoursite/wp-login.php
Comment following lines 770-773
Code
if ( isset($_POST['testcookie']) && empty($_COOKIE[TEST_COOKIE]) )
$user = new WP_Error('test_cookie', __("<strong>ERROR</strong>: Cookies are blocked or not supported by your browser. You must <a href='http://www.google.com/cookies.html'>enable cookies</a> to use WordPress."));
else
$user = wp_signon('', $secure_cookie);
It might work for some websites and some sites may show blank page. Moreover, this is not recommended,as this file may be overridden after wordpress update so try for second solution.
Solution 2:
yoursite/wp-content/themes/yourthemeFolder/functions.php
Place following code.
setcookie(TEST_COOKIE, 'WP Cookie check', 0, COOKIEPATH, COOKIE_DOMAIN);
if ( SITECOOKIEPATH != COOKIEPATH )
setcookie(TEST_COOKIE, 'WP Cookie check', 0, SITECOOKIEPATH, COOKIE_DOMAIN);
Updating of your theme may also loose these changes so please place this code in another functions.php, which is under your child-theme folder in your current active theme. Hope, this will help you.
Assuming you are running on a Unix/Linux type platform - please ensure you have copied your .htaccess file from your original server and updated any references to the old domain within that file. It will be in the root of your wordpress deployment (if you are using it).
Either that or you may have a reference to your old domain somewhere in your wp_options table within the database.
Be forewarned that as you have moved from one domain to another, images and media locations within posts may need to be updated. You can either do that yourself directly within the database, use a find/replace utility or manually re-point your images within your posts. An alternative method to fix your post data is to export all your posts from your old site (from within the admin panel) - Tools > Export > All posts; then manually update the URL within that resultant file before importing to your new site.
All of this and much more is covered over at codex.wordpress.org. For more information see this link:
http://codex.wordpress.org/Changing_The_Site_URL
IMPORTANT NOTES:
If you are going to modify anything directly within the database, make sure you read the section that talks about GUIDs
If you are using Better WP Security, there are other things you may need to do, but based on what you are describing, I doubt you have it installed.
I had the same problem with very similar circumstances and spec.
Eventually after trying all sorts of different solutions suggested online, I just renamed my active theme via FTP and then was able to login to the dashboard, I renamed my theme back and everything worked, I've no idea why but it may help somebody fix issues they're having.
I had the same problem and nothing works. After upgrading my php 5.3.x to 5.4.x it works fine.
Following step solve my issue
on wp-config.php
//define('WP_CACHE', true); // Added by W3 Total Cache Block this line
//define("COOKIE_DOMAIN", "www.domain.com"); Block this line
Delete following files from wp-content
object-cache.php
advanced-cache.php
db.php
I created my Multisite install long ago when you needed a plugin for domain mapping. So I had the file '/wp-content/sunrise.php' and in the wp-config define( 'SUNRISE', 'on' ); It's been working just fine until a recent update to WordPress.
I viewed these errors in my debug.log:
Undefined index: HTTP_HOST in ../public_html/wp-content/sunrise.php on line 10
Undefined index: HTTP_HOST in ../public_html/wp-includes/ms-settings.php on line 57
So I deleted the sunrise file and wp-config sunrise definition and added #max4ever/#duck_boy's cookie definitions to the wp-config file:
define('ADMIN_COOKIE_PATH', '/');
define('COOKIE_DOMAIN', '');
define('COOKIEPATH', '');
define('SITECOOKIEPATH', '');
That solved the problem. I can now login!! Note: I tried this definition and it worked as well. Taken from Multisite Setup Guide
define( 'COOKIE_DOMAIN', $_SERVER[ 'HTTP_HOST' ] );
I came across this error when trying to install a wordpress site on localhost. The problem was this line inside the .htaccess
Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure
It prevents cookies being set if not on https. Just had to remove the line.
I have found very good solution of this issue
There are possible following solutions for this error
Coding Error
Unnecessary Spaces in Code
Caching & Security Plugin
Check this article: https://www.scratchcode.io/cookies-are-blocked-or-not-supported-by-your-browser/
When you go to http://akademy.kde.org/
the register link is http://akademy.kde.org/register - no user in path
It goes to http://akademy.kde.org/user/register with user
This is a drupal website. How you think they did this? and how to make it stay at this path http://akademy.kde.org/register no user in path?
Possibly Drupal's path_redirect.
The index page for http://akademy.kde.org/register probably contains a simple redirect.
Also in PHP it is this easy header("Location: http://akademy.kde.org/user/register")
http://akademy.kde.org/register
simply redirect to
http://akademy.kde.org/user/register
...i guess they just make a shorthand path alias, go to http://yoursite.com/admin/build/path and you can make your owns (maybe you'll need to enable the path module, is boundled with drupal)
If you truly need a redirect, check out the path_redirect module as aularon suggested.
Check drupal's path_redirect module.
cookies/.htaccess/modified templates?
what is the normal http://drupal.foo/register/? url?
What I want to ask is if there is a way to find out if a web-server instance has URL Rewriting enabled. I need this in order to be able to instantiate the correct type of URL handler.
Theoretically you know in advance if you have it enabled or not and can use something to configure it. I would like, however, to be able to detect this setting automatically at runtime.
The URL rewrite rule would be something very simple like:
^/(.*)$ => /bootstrap.php
This guarantees that the relevant string is present in the REQUEST_URI, but doesn't pollute the _GET array.
Where did my research took me so far:
Apache.
In my opinion Apache has a very quirky approach, since it sets the REDIRECT_SCRIPT_URI header for rewrote URLs, but not for the ones that are not rewrote.
E.g. http://host/ana/are/mere would be re-wrote to index.php so the aforementioned header would be present, but http://host/ wouldn't be re-wrote.
Lighttpd.
Lighttpd with fast-cgi behaves OK, setting the REDIRECT_URI header if URL Rewrite is enabled for the current host. This is reliable.
Cherokee.
Well, for Cherokee there is no method that I found out, as it uses (in my opinion) a more complicated method for obtaining URL rewriting. (I.e., it's called internal redirect – and the fcgi process doesn't know that the request was redirected)
Also I haven't tested other http servers, as nginx, so if someone has some input on this matter I would love to hear it.
Not the most elegant solution, but you could create a directory, insert a .htaccess and a small php file and try to open it with curl/file_get_contents() from your actual code:
.htaccess
RewriteEngine on
RewriteRule ^(.*?)$ index.php?myparam=$1
index.php
<?php
//open with file_get_contents("http://yoursite/directory/test")
if($_GET['myparam']){die("active");}
?>
Although this might be acceptable during an installation, for performance reasons this shouldn't be used for every request on your site! Save the information somewhere (sqlite/textfile).
Update
Apache specific, but apache_get_modules()/phpinfo() in combination with array_search/strpos is maybe helpful to you.
It's already touched upon below, but I believe the following recipe is a rather waterproof solution to this problem:
Set up the redirection
Request a page through its rewritten url
If the request returns the page in question, you have redirection set up correctly, if you get HTTP 404 response, then it's not working.
The idea is basically that this works with just about any redirection method. It has already been mentioned, but bears reiterating, such tricks add quite a bit of overhead and are better performed only once (installation or from the settings panel) and then saved in the settings.
Some implementation details, choices to make and a little on how I came to this solution:
I remembered Drupal did such a check during the installing process, so I looked up how they did it. They had the javascript on the install page do an ajax request (synchronously, to prevent concurrency issues with the database). This requires the user installing the software to have javascript turned on, but I don't think that's an unreasonable requirement.
However, I do think using php to request the page might be a cleaner solution. Alongside not bothering with a javascript requirement, it also needs less data to be sent back and forth and just doesn't require the logic of the action to be spread over multiple files. I don't know if there are other (dis)advantage for either method, but this should get you going and let you explore the alternative choices yourself.
There is another choice to be made: whether to test in a test environment or on the normal site. The thing Drupal does is just have the redirection always turned on (such as in the apache case, have the .htaccess file that does redirects just be part of the Drupal download) but only write the fancy urls if the redirection is turned on in the settings. This has the disadvantage that it takes more work to detect which type of redirection is used, but it's still possible (you can for example add a GET variable showing the redirection engine either on a specific test page or even on every page, or you can redirect to a page that sets $redirectionEngine and then includes the real index). Though I don't have much experience with redirection other than with mod_rewrite on apache, I believe this should work with just about every redirection engine.
The other option here is to use a test environment. Basically the idea is to either create a folder and set up redirection for it, or remove the need for file system write access and instead have a folder (or a folder for each redirection engine). This has some disadvantages: you still need write access to set up the redirection for the main site (though maybe not for all redirection engine, I don't really know how you all set them up properly - but for apache you will need write access if you are going to turn on redirection), it might be easier for a bot to detect what software and what version of it you are using through accessing the tests (unless you remove the test folders after testing) and you need to be able to rewrite for only a part of the site (which makes sense for any redirection engine to be a possibility, but I'm not blindly going to assume this functionality). However, this does come with the advantage of it being easier to find out which rewrite engine is being used or basically any other aspect of the redirection. There might also be other advantages I don't know of, so I just give the options and let you pick your method yourself.
With some options left to the user, I believe this should help you set up the system in the manner that you like.
PHP has server-specific functions for Apache, IIS and NSAPI servers. I only have Apache but as merkuro suggested this works as expected:
<?php
if (in_array('mod_rewrite',#apache_get_modules()))
echo 'mod_rewrite enabled';
else
echo 'mod_rewrite not enabled';
?>
As PHP server-specific functions don't cover all the servers you'd like to test in this probably isn't the best solution.
I'd recommend merkuro's first answer - implementing then testing it in script. I believe it's the only way to get a good result.
Hope that helps!
You can programmatically check for the existence of mod_rewrite if the server is Apache by using the apache_get_modules() function in PHP:
$modules = apache_get_modules();
echo in_array('mod_rewrite', $modules) ? 'mod_rewrite detected' : 'mod_rewrite not detected';
This could be used as the first step, but it is not a full proof method by any means. Just because mod_rewrite is loaded does not mean it is available for your environment. This also doesn't help if you are on a server that is not Apache.
There are not many consistent methods that will work across all platform combinations. But since the result is consistent, you can test for that. Setup a special redirect, and have a script use PHP's cURL or file_get_contents() to check a test URL. If the redirect was successful, you will get the expected content, and you can test easily for this.
This is a basic .htaccess I setup to redirect ajax to ajax.php:
RewriteEngine On
RewriteRule ajax ajax.php [L]
The following PHP script will attempt to get the contents of ajax. The real script name is ajax.php. If the redirect fails, then it will not get the expected contents.
error_reporting(E_ALL | E_STRICT);
$url = 'http://'.$_SERVER['HTTP_HOST'].dirname($_SERVER['REQUEST_URI']).'/ajax';
$result = json_decode(#file_get_contents($url));
echo ($result === "foobar") ? 'mod_rewrite test was successful' : 'mod_rewrite test failed';
Lastly, here is the final piece of the script, ajax.php. This returns an the expected response when the redirect is successful:
echo json_encode('foobar');
I have setup a live example of this test, and I have also made available the full sources.
As all the awnser already mention, actually testing it is the only way to be sure it works. But instead of actually redirecting to an actual page and waiting for it to load, I would just check the header.
In my opinion this is quickly enough to be even used at runtime at a regular site. If it realy needs to be high performance, then ofcourse caching it is better.
Just put something like the following in your .htaccess file
RewriteEngine on
RewriteRule ^/redir/My/Super/Special/Hidden/Url/To/Test/$ /redir/longload.php [L,R=307]
And then you can use the following php code to check if mod_rewrite is enabled.
<?php
function HasModRewrite() {
$s = empty($_SERVER["HTTPS"]) ? '' : ($_SERVER["HTTPS"] == "on") ? "s" : "";
$sp = strtolower($_SERVER["SERVER_PROTOCOL"]);
$protocol = substr($sp, 0, strpos($sp, "/")) . $s;
$port = ($_SERVER["SERVER_PORT"] == "80") ? "" : (":".$_SERVER["SERVER_PORT"]);
$options['http'] = array(
'method' => "HEAD",
'follow_location' => 0,
'ignore_errors' => 1,
'timeout' => 0.2
);
$context = stream_context_create($options);
$body = file_get_contents($protocol . "://" . $_SERVER['SERVER_NAME'] . $port .'/redir/My/Super/Special/Hidden/Url/To/Test/', NULL, $context);
if (!empty($http_response_header))
{
return substr_count($http_response_header[0], ' 307')>0;
}
return false;
}
$st = microtime();
$x = HasModRewrite();
$t = microtime()-$st;
echo 'Loaded in: '.$t.'<hr>';
var_dump($x);
?>
output:
Loaded in: 0.002657
---------------------
bool(true)