Manual Url Culture Rewriting in DotNetNuke Request - url-rewriting

I'm working with dotnetnuke 7.
I'm not using any rewriting modules and don't want to use them.
When content localization is enabled, url has the following view:
my_training_host/en-us/my-page.aspx
I want to change manually the display url so, that instead of full culture in query, the two letter culture (neutral culture) will show:
my_training_host/en/my-page.aspx
Does anyone have similar problem ?

If you ever change your mind about using a rewriting module, UrlMaster is the module for that. If not, then DNN 7.1 now adds support for creating url providers as extensions. More details at http://www.dnnsoftware.com/blog/cid/154604/Introducing-DNN-Extension-URL-Providers

I am using Open URL Rewriter for DNN - it does exactly what you ask for with it's default installation - no further config required.
And it's open source in comparison with UrlMaster.
In case of you use version 1.3.1 of Open URL Rewriter with DNN 7.04 to get two letters only for multilingual sites you have to make sure:
you create site aliases for each language with the two letter part you desire and
enable those entries as primary aliases (you need one primary alias for each language), for example for two languages (en & fr) you need to set three primary aliases like the following:
✔ www.yourdomain.com
✔ www.yourdomain.com/en us-US
✔ www.yourdomain.com/fr fr-FR

Related

How to add prefix in URI while loading XQuery file using ml-gradle

I am using gradle 6.8 and MarkLogic version is 10.0-5.2,
My XQuery code is in directory \ml-gradle\src\main\common. When I run the command mlLoadModules to load XQuery into the modules database it loads with default URI /common/test.xqy.
I want to add some prefix to the URIs e.g. /rsc/common/test.xqy. How can I achieve that?
Note: I don't want to create an extra folder in my source for prefix "rsc".
It's not supported, though you could write a custom Gradle task to change the URI to whatever you like.
Why do you not want to create an "rsc" folder above "common"? I think other developers would find it much more intuitive that "rsc/common/test.xqy" becomes "/rsc/common/test.xqy" when loaded, rather than "common/test.xqy" becomes "rsc/common/test.xqy", which begs the question - where is "rsc" coming from? And then that developer would need to understand what property / custom code is adding that "rsc".

Swashbuckle, multiple API versions, and virtual directories

I am looking at using Swashbuckle/Swagger to document my WebAPI solution. The developer portal would be something like https://myapi.com/, while the versioned API is https://myapi.com/v1/users.
The version part of the URL maps to a virtual directory, containing the binaries and config files for v1. When version 2 ships, we create a new virtual directory under the root, so now we have https://myapi.com/v2/users/some_new_endpoint_not_in_v1. This means that save for bugfixes, there is no need for any of the binaries of older versions to be touched, which reduces the likelihood of some developer accidentally breaking backwards compatibility for our customers.
However, I can't see how to configure Swashbuckle to look at those virtual directories to get the controllers/actions and XML comments to parse. The MultipleApiVersions configuration option seems more targetted at people who throw all their supported versions into one set of binaries (either by namespaces or controller names), and not by separating them into separate processes.
Any suggestions as to how I can bend Swashbuckle to my will? Should I just install Swashbuckle into the individual virtual directories as single API versions, so the docs becomes something like https://myapi.com/v1/swagger? My portal would then do the necessary work to expose the different API versions.
Update
I did try the latter approach, and for the documentation at least, it works OK. The problem is then that the URL for the Swagger spec then becomes https://myapi.com/v1/swagger/docs/v1, and I would rather not have that second v1 in the URL. Unfortunately Swaashbuckle at least expects the version number to be in the relative path, not in the base URL.
Having those would work:
Swagger UI at the root of your API site (nothing to do with Swashbuckle),
multiple virtual directories for your versions ("v1", "v2"...)
To achieve this:
the custom discoveryPaths array in Swagger UI javascript would look like below, with added "/spec" suffix (or whatever suits you, as SwashBuckle is not handling the c.SingleApiVersion with an empty version value):
var currentUrl = 'https://myapi.com/';
window.swashbuckleConfig = {
rootUrl: currentUrl,
discoveryPaths: arrayFrom('v1/swagger/docs/spec|v2/swagger/docs/spec'),
booleanValues: arrayFrom('true|false'),
validatorUrl: stringOrNullFrom('null'),
// other settings ommitted for brevity.
oAuth2AdditionalQueryStringParams: JSON.parse('{}')
};
Removing c.EnableSwaggerUi from your Web API sub apps

Firefox-Addon: Add search engine with varying URL and suggestions

my Firefox addon shall add a search engine, that
provides suggestions
gets its search template URL specified on runtime (i.e.: template URL depends on the preferences of the user)
And I don't see a way to do both at the same time.
I see two options to add a search engine:
addEngineWithDetails
addEngine
addEngineWithDetails() allows me to add a search engine with the template URL. But it does (apparently?) not allow to provide a suggestions URL.
addEngine() allows me to add a search engine that is specified in an XML file. But if have that file saved locally in my addon directory (e.g. chrome://example-engine/content/search.xml), how can I change the template URL on runtime? And using an online XML is an unsafe options since the internet connection could be broken or bad during the addon install.
First fo all, you're right, addEngineWithDetails does not support suggestions.
The way to go would be to use addEngine (and removeEngine).
As for the "dynamic" part of your question: While I didn't test it, the implementation seems to happily accept data: URIs. So you could:
Construct a data URI using whatever methods you like (even constructing a full XML DOM and serializing it).
Call addEngine with the data URI.
When the user changes a pref, remove the old engine, and construct a new one.

IIS globalization and Spanish (Latin America) es-419

IIS does not handle the "es-419" correctly. Is there a workaround to get it to work? I am using the following to get the Thread local uiculture set.
<globalization uiCulture="auto" culture="auto"/>
That works fine for all the locales i have tried except for "es-419" which is common from Chrome browsers. If "es-419" is in the list it just uses the default local instead of es.
See if this helps you out to create a custom culture, since the numbered cultures aren't supported.
How to: Create Custom Cultures

What is a clean way to use a "/" in a part of a URL

In an MVC framework, I have a model with an "identifier" field. This field can be whatever is used by the user as their unique identifier. I then use this identifier field in URLs to access the relevant resources.
/people/<identifier>/
In one such case, the user is using identifiers of the format 00/000. The quick among you will have spotted the problem straight away - how do we know which part is the identifier, and which part the action?
The obvious solution is to use URL escaping (%2F being the relevant code). However, this confuses my apache load balancing proxy as well as the application server on our demo box (running passenger). Although annoyingly this works fine on the local development servers. URLs including %2F seem to cause 404 errors from the server (not the application!).
What i'm looking for is a general approach to solving this problem, while keeping a tidy URL.
The stack which caused this problem is: Ruby 1.8.7, Merb 1.0.12, Apache load balancing to a thin cluster on production, Passenger on the demo server, and working with unproxied thin on development.
The cleanest way would be to prevent the user from entering in a forward slash character in the first place. If it is necessary to support this format, then there is no way around having to use URL escaping.
You could always use a home-grown encoding that replaces / with some other character that is never used in your identify field and then converts it back when reading it from the URL.
For example:
http://yoursite/people/00/000
becomes
http://yoursite/people/00-000

Resources