I started using ModX yesterday. Prepared my multilingual website using this tutorial: http://www.multilingual-modx.com/blog/2011/multilingual-websites-with-modx-and-babel.html.
Everything works perfectly. I have two contexts: web (domain.com - English) and nl (domain.nl - Dutch). I translated main resource for nl context as well as other resources.
I faced only one problem: why domain.com returns error 404? It works perfectly for domain.nl/index but cannot make it working for domain.nl.
Any suggestions?
Edit
Just noticed, that Wayfinder is generating domain.nl/index URL for translation of main resource. Weird.
You need to set up site_start variable under Context Settings tab. You need to provide an ID of the existing and published resource.
Please follow this link for more informations.
The tutorial you linked mentions only the parameters site_url and cultureKey to be set for every context. You should also set http_host to domain.com/domain.nl and site_start to the id of your desired "home resource" for each context in the context settings.
You can probably fit this description from the modX manual to your needs.
(although it is for running a multilingual page with different subdomains).
Related
I am trying to change my site uid(mangou-uk to mg-uk) in hybris. I changed in hmc but getting 400 error when I click on homepage category links and also in some other pages. What are the steps to follow to change site uid in hybris. Can anyone help me on this please.
Have you also changed the below properties in your local.properties file?
media.mangou-uk.http=http://localhost:9001/
media.mangou-uk.https=https://localhost:9002/
website.mangou-uk.http=http://localhost:9001/
website.mangou-uk.https=https://localhost:9002/
If you change your site uid from mangou-uk to mg-uk then you would also need to amend these properties accordingly, e.g.:
media.mg-uk.http=http://localhost:9001/
media.mg-uk.https=https://localhost:9002/
website.mg-uk.http=http://localhost:9001/
website.mg-uk.https=https://localhost:9002/
(the URL's might be different of course depending on your environment)
Have you restarted Hybris ? Usually this is cached in your session by the DefaultUrlEncoderFacade so most likely a restart would be enough.
Or try to delete and recreate the storeFront url Encoding Attribute from the HMC if you can't restart.
Did you also adjust the "URL Patterns" accordingly in the hmc?
It's under WCMS -> Websites in the hmc. For your website you will have to adjust the URL Patterns (in the Configuration section) . At least you have to do that in case you use the ?site=SITEID parameter approach.
Changed the site uid in hmc.
Changed the base store uid in hmc against the each website.
Changed the properties as suggested by #Alexey
Now its working fine.
I have set up a small XPage and have until now used the full path to the Xpage for testing, i.e.
http://devsrv1.magerman.ch/Development/Schulungen/Schulungen1_0/Schulungen_(1_0)_Dev.nsf/HomeWithDataView.xsp
I then tried to apply a Web Site Document
But the links are no longer currently functioning. I have the feeling that I'm missing something pretty basic, and am unsure as to what the best practice is. I'm quite happy with having the original request to the hostname resolve to a full path, i.e.
input
schulungen.magerman.com
and have it resolve to
schulungen.magerman.com//Development/Schulungen/Schulungen1_0/Schulungen_(1_0)_Dev.nsf
but haven't found a way to do this elegantly.
At the moment, my relative links '/OtherXpage.xsp' fail as they try to get to schulungen.magerman.com/OtherXpage.xsp
Any pointers?
Create a Web Site Rule. You can create it from your Web Site document in edit mode with action button " Web Site ... / Create Rule".
You can find a description how to fill the fields here.
The problem is usually that you need to add a trailing slash to the hostname
http://www.xpagedeveloper.com/2013/quicktip-get-right-path-when-autolaunching-an-xpage
my xPages app (with oneUI theme set) works perfect when I use e.g. this URL:
https://testserver.xxxx.xxxx.com/app_folder/Home.xsp
and then our Domino admin mapped it to a new URL
https://myApp.xxxx.xxxx.com
that by default opens Home.xsp page
but now I see several UI issues - some icons/images are not shown, some controls displayed incorrectly.
What could cause this problem? It's the same Domino server but just two different ways to log in. Is it something related to "XPages Resource Servlet" configuration? Where can I check it?
For example. I have an image on xPage that has following resource:
"../../oneuiv2/images/sortDescending.png"
then when I log in through https://myApp.xxxx.xxxx.com - it doesn't show the image...
OK, then I replaced it with:
"/.ibmxspres/domino/oneuiv2/images/sortDescending.png"
same result.
but this works:
"/.ibmxspres/global/theme/oneui/images/sortDescending.gif"
I can replace all images/icons with new resource URLs but anyway other standard controls are not shown correctly..
Based on our short discussion your problem is in wrong URLs.
So why one URL works and the other one doesn't? Concatenation, in my opinion. Browser, JS frameworks (DOJO) and JS programmers in general tend to use either relative URLs or cut/concatenate URL string. This my result into URL that is not understandable by server.
In your case check URL mapping made by your admin - does it apply to all URL formats used by XPages? Are those transformed URLs accessible on server (enter them in URL bar of browser)? That is the key to get your XPage working.
OK.. it's fixed. The problem was in Virtual Server Mapping document.
Names.nsf -> Web -> Web Configuration -> Virtual Server -> Mapping tab...
we had to set
HTML directory: domino\html
which was
HTML directory: /myappdbname.nsf
instead
Is there a solution to the following that I am missing in SharePoint/CAML. Note that I'll give a specific example of using a URL on a Redirect Page (publishing feature content type), but the issue is broader in scope than provisioning a Redirect Page. It is really a question anywhere a "URL" field/property can be set (web parts, pages, etc).
Like most SharePoint developers, I have a set of environments: "DEV", "QA", "STAGING", and "PROD". I have a few "locale" specific sites in each environment:
www.mysite.com
us.mysite.com
uk.mysite.com
etc...
Sites in each environment, other than PROD, have an environment prefix associated with them, for example:
us.dev.mysite.com
us.qa.mysite.com
us.staging.mysite.com
Probably a pretty common setup...
I have a need to redirect users to a page that only exists on the "www" site from each of the locale specific sites. I need the redirect to redirect users to appropriate "www" site for the environment they are currently in. For example, if I am in dev in the uk locale, and I visit the redirect page, I should be redirected to the www dev site.
I was hoping to use a "Redirect Page" from SharePoint to accomplish this. I was going to setup a feature (with module elements) to provision an instance of the "Redirect Page" content type. This allows me to specify a url to redirect users to. If I am provisioning the page through CAML, however, I need a way to ensure the redirect is appropriate for the environment being specified. I cannot trust myself, or other devs, to remember to change the URL each time we build and deploy the wsp to each environment.
Is there anyway in SharePoint/CAML to do some sort of token replacement based on some switch when specifying field/property values?
I'm not sure I understand you requirements entirely, but for the variance of environments (Dev, QA, Staging, Prod), I would use Chris O'Brien's 'Config Store' feature:
http://www.sharepointnutsandbolts.com/2008/05/introducing-sharepoint-config-store-for.html
This will create a simple list where you can store infomation specific to the current environement.
This combined with Gary Lapointe's stsadm extentions:
http://stsadm.blogspot.com/2007/08/stsadm-commands_09.html
You can use this to push out the correct values per environment to your 'Config Store' and in your code, query the 'config store list' for the environment value.
For sites that represent different countries, you can vary them on the regional settings property for that site/site collection/web. This adds another dimension to check in your code.
In your case, you may have entry in the config store called 'MyPrefixUrl' and call its value + relative path to redirect the user to the correct place.
Hope this doesn't confuse you.
I have a WSS 3.0 system using SSL where every page is supposed to be served as https. Almost all pages do come out as https, but in certain cases I click on a link and that brings up an http version of a page (which does not load). In those cases I have to put the 's' in by hand to get the page to load. Places where this happens are:
/_layouts/newgrp.aspx : when I try to create a new group, it takes me to http://server/_layouts/newgroup.aspx, although it should be https. The page does not load at http. It does load if I change the url by hand.
/_layouts/edtgrp.aspx : same thing as newgrp.aspx
if I go into a document library and view version history for a file, the URLs to the individual versions of that file are http. Interestingly, the browser status bar also indicates http when I hover over them (so it seems that SharePoint gets confused when it generates the links, rather than when I click on them)
To fix this, I have tried adding some javascript to the DOM that searches for instances of http and replaces them with https. This works in some cases, but there are some places where javascript can't reach, for example when SharePoint provides the target URL in response to a POST request, which I think is the case with newgrp/edtgrp.aspx.
I have also tried adding ISAPI filters to redirect pages from http to https. This seems to cause redirect loops, and in any case I'm not sure if such filters would preserve querystring or POST information.
Has anyone seen this problem?
Update: We have switched to ISA from Squid, and the problem continues in the version history, but not on new group or edit group. We have not seen any improvement yet from changing AAM settings.
Places where this is happening in ISA:
"Version History" under item in list or document library
"Manage Permissions" under item in list or document library
"Alert Me" under item in list or document library
"Add Users" menuitem in "People and Groups" page
"Group Settings" menuitem in "People and Groups" page
"Edit Group Quick Launch" menuitem in "People and Groups" page
"Set Up Groups" menuitem in "People and Groups" page
"List Settings" menuitem in "People and Groups" page
Not sure if this is it, but have you checked your alternate access mappings to make sure they say https instead of http?
I would echo the suggestion to check your Alternate Access Mappings. Is the SSL being done on the SharePoint Front Ends, or is it being done via a piece of dedicated SSL hardware?
Use an HTTP Module to modify SharePoint's output so that links are always changed to https. Such a module can plug into IIS and modify the HTML of anything rendered. I've used this technique to make SharePoint XHTML compliant and it works well.
Even better, almost all of the work has already been done for you. The UrlRewritingNet module is open source and available for free download. It should work fine for your SharePoint site. This tool has great documentation and uses regular expressions to match which URLs to alter. It should be pretty easy to write one for your case, e.g. ^http://. There's also many more advanced options you can take advantage of if necessary.
If you'd prefer to write your own then there is a good article called Rewrite.NET -- A URL Rewriting Engine for .NET on the 15 Seconds site.
Finally, if you're using IIS 7 you could try its URL Rewrite Module. I've never used this myself and don't know if it works with SharePoint, but it's the most UI-driven solution available.
Add a redirect in IIS from http to https. Every time you access that page it will redirect you to your https page instead.
I would also suggest placing WSS on another server to see if you have the same problems. If you don't, you might need to rebuild/migrate your stuff over.
Alex answered this question with an approach that I think will generally work. Here is how I fixed this specifically.
It looks like when a SharePoint aspx page is loaded, it populates a javascript structure of type ContextInfo (defined in init.js), which is instantiated in the variable ctx. That structure has a member called httpRoot, which is later used in core.js to build menuitems in various dropdown.
This ctx.httpRoot is for some reason populated in javascript in the aspx files created by SharePoint with a line like this:
ctx.HttpRoot = "http:\u002f\u002fsubdomain.domain.com";
Yes, it has Unicode slashes and it has http instead of https. I have no idea why. But, fixing this line of javascript seems to fix the problem.
I changed the line by adding a URL translation rule in ISA that converts http:\u002f\u002f\ to https:\u002f\u002f\ . I suspect that an HTTP module that makes the same replacement would also work. Or possibly some well placed javascript that reassigns the variable at some point.
I still believe this is not ideal and there must be a more appropriate way to fix these links.