DNN 7.4 friendly URL (gclid) - dotnetnuke

I have issues with URL rewrite in DNN 7.4
I have another web site running on DNN 7.3 , there everything works perfect! For example if open:
http://www.example.com/Some-test-page?gclid=TEST
it will open the same URL without reWrite! But now in new version of DNN (7.4) if i open some URL , result will be:
http://www.example.com/Some-test-page/gclid/TEST
So for example my AdWords not working at all.
Find this topic: http://www.dnnsoftware.com/wiki/keeping-querystring-items-out-of-the-url-path-in-dnn
In my HostSettings table , I don't have record for
SettingName = 'AUM_KeepInQueryStringRegex'
So I inserted the following statement:
insert into {databaseOwner}{objectQualifier}HostSettings (SettingName, SettingValue) values ('AUM_KeepInQueryStringRegex', '/nomo/\d+|/runningDefault/[^/]+|/popup/(?:true|false)|/(?:page|category|sort|tags)/[^/]+|(/utm[^/]+/[^/]+)+')
Clear cache, restart app pool. And nothings happen. I was check DoNotIncludeInPathRegex value as mentioned in NOTE:
https://github.com/dnnsoftware/Dnn.Platform/blob/release/7.4.0/DNN%20Platform/Library/Entities/Urls/FriendlyUrlSettings.cs
But it is same:
public const string KeepInQueryStringRegexSetting = "AUM_KeepInQueryStringRegex";
By the way this problem is reflected to a search engine that also does not work. How other people works with version 7.4?
Any ideas?

FOUND A SOLUTION !!! ..
Installed this module : http://dnnurlmanagement.codeplex.com/
and uncheck : Redirect Unfriendly .. this solve my issue..
Something interesting , if install same module on 7.3 and check same checkbox , 7.3 begins to behave like 7.4 .. so may be this is a future in new version , but totally not working for me.

Related

Pantheon Drupal 7 setup issue with clean url

On my site under admin section node view (node/xxx) is working fine but when I am trying to edit a node (node/xxx/edit) give me following error
ERR_TOO_MANY_REDIRECTS
This issue is only on Pantheon when I do it on my local server it is working fine.
I already checked .htaccess and web.config file. The same configuration is working for me with another setup
Finally i got solution. Actually i installed ThemeKey module and the ThemeKey Debug creating redirection issue on Pantheon only i disabled it and site is working.

Laravel: view not found

I'm developing an internal site using Laravel 4, I have everyone working on my laptop (Windows & Apache).
I've now moved the site to a Turnkey Linux 13 VM for beta testing and have encountered the following problem:
The home page loads fine.
When I come to load the About page (or any other page) I get "requested URL /internal/about not found".
The Laravel config is exactly the same.
Apache's document root is set to: /var/laravel/public.
Apache gives the following error in the logs:
"File does not exist: /var/laravel/public/internal"
Yet the Laravel config is specifying the default view directory and the home page loads fine.
It was an Apache config issue, mod_rewrite wasn't enabled (it was on my Windows laptop), simply enabling this resolved the issue.

CakePHP without mod_rewrite causes 404 errors

I'm pretty new to Cake, so I tryed to start with the blog tutorial.
I installed CakePHP 2.3.8 in webroot.
Configured SQL and deleted all 3 .htaccess-files, cause i have no mod_rewrite. In core.php I activated
Configure::write('App.baseUrl', env('SCRIPT_NAME'));
I created the Posts-Model, Controller and the index-View like the tutorial says.
The APP/View/Pages/home.ctp tells me, everything's allright.
But when i try to open /posts/index i get a 404. Why?
Without mod_rewrite the urls look like www.example.com/index.php/controllername/actionname/param, i.e. in your example you have to call /index.php/posts/index (or /index.php/posts/).

cakephp running on nginx accessing plugins

I used cakephp for a couple years now running on Apache.
I am running php 5.3 and cakephp 2.2
I have installed nginx and have a very simple cakephp model working (few tables using scaffolding) and this works perfectly.
I have just install the debug_kit Plugin under the standard APP/Plugin directory and access a page and the logs show it can't find the files
The access log shows it goes to get /debug_kit/css/debug_toolbar.css and the error stays it can't find app/webroot/debug_kit/js/jquery.js
If I try other simple Plugins Chk in essence it can't find the ChkController however the logs show rewritten data: "/index.php", args: "url=Chk"
It seems to imply that for standard models the rewrite is working but for Plugins when it looks up the file the base dir for the Plugin is not being calculated
Any ideas or samples
Many Thanks
Si
I'm pretty sure this is related to your rewrite rules. I don't know how your nginx rewrite rules look like but these here are working fine for me using any version of cake 2.x.
if (-f $request_filename) {
break;
}
if (!-f $request_filename) {
rewrite ^/(.+)$ /index.php?url=$1 last;
break;
}

Backbone routes break on refresh with Yeoman

I am building an app with Backbone and Yeoman. I am having an issue with the routing.
I have the following routes set up:
'test' : testMethod,
'' : index
I have set up pushstate:
Backbone.history.start({pushState: true});
I am using Chrome
If enter myApp.com#test the url changes to myApp.com/test and testMethod() fires correctly.
However if I try goto myApp.com/test directly or refresh after the browser has changed the url from # to / then I get a 404.
I am using the Yeoman built in server to test the pages. Could this be causing the issue?
I am not sure if you are using BBB within Yeoman. If you are, this should not be an issue. If you are not using BBB, this is a known issue. BBB has it's rewrite rules setup correctly to use pushstate, but yeoman's built in server does not seem to adopt this. You could edit your grunt.js file with your own rewrite rules to get pushstate working correctly. Some of the users in the above mentioned link have done this successfully.
When your app goes live, you will either need to serve those urls through your server or edit your rewrite rules to do the same. If the latter, and your application relies on SEO, SEO will suffer greatly.

Resources