I see this behavior from time to time where a site's URL will be in all capital letters when linked from the navigation. The site's name is not all caps, and the URL is properly cased in most situations. The all uppercase treatment appears to come and go, and is not related to anything. Has anyone else seen it or know how to stop it from happening?
I've just looked into this myself. It's part of the internal caching; sharepoint converts part of the links to uppercase to make the comparison case insensitive. As far as I can tell there's nothing you can do about it.
http://support.microsoft.com/kb/953457
Check the welcome page setting for the site - that's where the link used in navigation comes from.
I have seen it... my development team caused it when they created a custom navigation provider and needed to check values in the URL. They converted the URL to all uppercase to make the string finds easier.
Related
Im trying to modify search parameter in Application Layout Search, to accept dot(.) as literal part of search item for filtering a view..
for example...
"Mr. Smith" will not show up in the view, but
"Mr.Smith" will..
digging deeper with google debugger, I found the function _xspAppSearchSubmit where I can simply change the code encodeURIComponent(val) into encodeURIComponent(val.replace(/s+\.s+/g,'')
which worked when i tested on console. The s+ to remove spaces, \. to keep the dot as literal.
BUT somehow, I cannot find this function in the ApplicationLayout1 custom control, and listed only one event - onItemClick.
Is it possible to add an "onChange" event?
There's an option and optionParam property there but not sure how to apply this.
Im a newbie with xpage and this control, can someone help me work around this, I've checked other sites about this but doesn't explain this kind of issue. I've also checked encodeURIComponent functionality, but it still interprets dot as command. I also learned this dot works like * wildcard.
the Application Layout is ccBaseUI from "One UI", and setup Basic Application Configuration.
code snippet capture
We have inherited a web application in Lotus Notes in which we are trying to introduce XPages (we are new to both Lotus Notes and XPages, please forgive our inexperience).
We have a view that we are trying to swap with an XPage. The current view is called like this from the application menu (the view is being called from a form):
<a href="FRVWFACSPROVXEstadoAno?openform" target="ifat">
And we are trying to call the XPage like this:
<a href="Prueba.xsp" target="ifat">
For some reason, the link is expanded at runtime to this:
http://tbsdesa.es.lladro.com/FORMACION/CARLOS/TBS_AGORA_FIN.NSF/Prueba.xsp
The page is not found because the database name is in uppercase (in fact, if we change TBS_AGORA_FIN.NSF to TBS_AGORA_FIN.nsf, it works). It is also strange that the current link is in uppercase, too, but nevertheless it works:
http://tbsdesa.es.lladro.com/FORMACION/CARLOS/TBS_AGORA_FIN.NSF/FRVWFACSPROVXEstadoAno?openform
We would like to know why the database is in uppercase. Could the Domino server be doing this?
I'm going to assume based on your question that you're calling your link from a form or page that's rendering as HTML. Since it's a relative link, you're probably navigating to it through a link that includes uppercase for the .NSF in the title. This can be solved either by fixing all your links so that .nsf is lowercase, or by calculating your XPages links better.
To do the latter, I usually do the following for XPage Links:
Link
Where XPage.xsp is the name of my xpage and the value of the Computed Text is:
"/" + #WebDbName + "/"
This will calculate the link based on what Notes wants to refer to the database as.
Hope this helps.
What OS is the server running on? If the server is running on Linux/Unix then you need to be aware that directories and filenames are case sensitive. The tricky thing, however, is that once they have been opened they are cached by the server - and will work without being case sensitive (for some time...). This can be really tricky to troubleshoot if you are not aware of the cause ;-)
I agree with the possible solution suggested by Aaron, however, it really should not be necessary... It should be better to leave that to the server.
If you are running on a *nix OS then ensuring that all paths and filenames are in the same case (I use lowercase) is a good practice...
/John
I want to search some URL within my company's web site, and with at least one "get" parameter.
Something like http://www.mysite.com/info.php?id=212
So, there should be a ? symbol in it.
However, I tried to use
site:.mysite.com filetype:php inurl:?
And got so many pages without any GET parameter, why does the inurl:? not work?
As you can see here http://support.google.com/websearch/bin/answer.py?hl=en&answer=2466433:
Generally, most punctuation and special characters are ignored in Google Search.
That includes the question mark, and that's why your search doesn't work.
I have a URL stored in a Sharepoint 'Link to a document' that contains the Nordic Character 'Ø' as hex(%D8). Sharepoint is encoding the % symbol, (thus making it %25D8).
If I enter the URL directly into an address bar, it works fine.
If I don't URL encode it, I still get the same problem.
Anybody got any ideas?
So what happens if the URL is stored as 'Ø' in the URL instead of already having it encoded?
Also do you have any special process running that stores it for you? Because if you don't have any custom code interacting with this, this is probably better asked on serverfault.com.
Looking through my search logs from time to time, I notice that by far the biggest user of my search engine is the google-bot. What gives? Is it looking for content that might not be directly accessible through navigation? If so, how does it know which words and phrases to look for (they're surprisingly relevant). Does it check the most popular keywords on the site? I know I seem to be answering my own question here, but this is really only working it out from first principles. I'd like to hear from someone who knows what they're talking about (i.e. not me).
If your search form's method is get instead of post, each search has its own url, and people might be posting those urls elsewhere. Or if you have a (possibly inadvertently) publicly accessible webstats page that listed those urls, that's another common way for search engines to stumble upon your internal search urls. A third way I've seen is sites that list recent searches on their pages, but this is more intentional. "MySQL Performance Blog" does this to an annoying extent, so any search of their site from google yields hundreds of pages of similar searches, even if none of them found what they were looking for.
Edit: Looks like it does on occasion, but only GET forms:
http://googlewebmastercentral.blogspot.com/2008/04/crawling-through-html-forms.html
Google will use words that occur on your site in search boxes to try to find pages that it can't otherwise.
Google says that for the past few months, it has been filling in forms
on a "small number" of "high-quality" web sites to get back
information. What words has it been entering into those forms? Words
automatically selected that occur on the site, with check boxes and
drop-down menus also being selected.
http://searchengineland.com/google-now-fills-out-forms-crawls-results-13760