I want to set multi site setup in Visual studio for multiple sites in Sitecore. I want to have separate Layouts/sublayouts/ascx and code behind for all websites. Also i want separate config files for each website so that it will be easy to update individual sites. i didn't find any appropriate documentation from web.
Any help
This is what I do as far as Sitecore and Visual Studio structure goes:
1) Create sub folders for your sites in Sitecore within the Content, Layouts, Templates and Media Library folders.
2) Create sub folders in your web root on disk. Do this for the Layouts/View folder, but also for the client-side includes (css/js).
So you will get a structure like this:
3) Create a separate web application project for each site and place the .csproj file inside the web root.
Then include the necessary folders per project (so the Include/Site1, Views/Site1 folder are included in the project for Site1, etc).
4) Configuration is a little tricky, because you will always share one Sitecore configuration with all the site instances.
But what I do for settings is prefix them with the site name, like this:
<setting name="Site1.MySetting" value="MyValue" />
You can then put that in separate config files in the /App_Config/Include folder.
That will give you at least some separation of configuration per site.
I would create at least one sub folder within the Include folder to ensure your custom configuration is included as last.
5) I will usually also add one "site" project called Global that contains everything that is shared between the instances.
That will mainly contain templates in Sitecore and in the VS project it contains references to /sitecore files, global.asax, web.config and App_Config files.
There are of course many more factors to account for, but these are the basics for setting up the solution.
I think this should be the documentation you are looking for:
http://sdn.sitecore.net/Articles/Administration/Configuring%20Multiple%20Sites.aspx
Here is a great blog I've read:
http://www.sitecore.net/Community/Best-Practice-Blogs/Topics/Multisite-Management.aspx
I have multiple solution files set up for multiple sites.
A suggestion would be to also move the App_Config, web.config, and bin libraries into the solution helps.
Setting up Sitecore Rocks will also be a great asset.
Edit: More Info
Hedgehog development has an amazing plugin for Sitecore as well called Team Development for Sitecore (TDS). You can check it out here.
http://www.sitecore.net/Partners/Technology-Partners/Hedgehog-Development.aspx
http://www.hhogdev.com/products/team-development-for-sitecore/overview.aspx
I point my solution at: \inetpub\wwwroot\sitecore\Website
At the root of my solution:
App_Config folder which holds my connection string configs and Lucene configs.
Libraries folder which holds my application specific dlls.
Sites folder which holds the sites and all the respective sublayouts. Sites contains multiple websites which all contain at a minimum of css, Images, layouts, Services, Scripts, and Sublayouts.
The server's web.config with web.debug and web.release.
All of this is checked into Team Foundation Server with build servers and more.
For the layouts and sublayouts you can separate them like Rudd van Failer showed us above in VS, using directories named like your site (and point the layouts/sublayouts in sitecore to the appropriate places).
i.e.
For configuring your sites in VS, add all your site configurations to the SiteDefinition.config (or setup separate projects that contain their own SiteDefinition.config pointing each site to the appropriate sitecore location). i.e.
<sites>
<site name="site1" patch:before="site[#name='website']" virtualFolder="/" physicalFolder="/" rootPath="/sitecore/content/" startItem="/site1/home page" />
<site name="site2" patch:before="site[#name='website']" virtualFolder="/" physicalFolder="/" rootPath="/sitecore/content/" startItem="/site2/home page" />
</sites>
Related
We have 3 servers – production (CF2016 HF4), staging (2018.0.07.316715) and I have a local install on my Windows 10 desktop (2018.0.07.316715).
All were setup following the lockdown guide.
We have thousands of e-mail templates stored as .htm files which are included as a cfinclude or savecontent in cfmail. The .htm files generally have a few cfoutputs and several cfincludes that bring in other pieces of templates.
On staging, none of the CF in the templates are working. Includes are skipped and output is just #output#.
Permissions seem the same on folders, so I’m thinking this may have something to do with an IIS handler or mapping to Jakarta issue, but I'm not sure where to start to troubleshoot this one.
In CF2018 Admin on the Settings page is a list of file extensions that are allowed to be included using cfinclude. Somewhere between install dates of these servers the default of CFM, CFML, HTM, HTML was changed to just CFM, CFML. Adding HTM and HTML into the problematic server fixed that issue.
I'm trying to get VuePress to work well with GitHub Pages and a custom domain. I have the site working -- https://www.southertonrr.com (repo) -- as long as I manually add a CNAME file to my output folder ('./dest', or in my case, './docs', because that's where GitHub Pages looks for the site) every time after I issue a build command. Otherwise, I assume the build command deletes everything in my output folder and rebuilds the entire site.
Is there a way to get vuepress build to either leave that file alone, or copy a CNAME file from my ./src to my ./docs? Should I be looking at the configureWebpack config to use webpack to do it? (I'm new to webpack.)
Different product completely, but I noticed that Docusaurus for React has a CNAME config setting that does this for you, so I thought I'd check to see if the VuePress community had something similar.
See relative document
Sometimes you may need to provide static assets that are not directly referenced in any of your Markdown or theme components - for example, favicons and PWA icons. In such cases, you can put them inside .vuepress/public and they will be copied to the root of the generated directory.
I am running multiple applications (websites) that use common CFCs between them such as for string formatting and text parsing.
I am finding it difficult having to update the same functions across multiple sites and would like to just have one library of common CFCs that any ColdFusion application can take an instance of. It would be nice if the location of the CFC library could be anywhere (on the same server or maybe on a different server or in the cloud).
Looking at documentation I am not clear if this is possible and how to do it. If not what options do we have for code resuse across applications? Can anyone point me in the right direction please?
Pretend your CFCs are custom tags and use the documentation regarding custom tag locations. Here is one.
Here is some text from that link.
Storing custom tag pages
You must store custom tag pages in any one of the following:
The same directory as the calling page
The cfusion\CustomTags directory
A subdirectory of the cfusion\CustomTags directory
A directory that you specify in the ColdFusion Administrator
In other words, if you specify a location in the ColdFusion Administrator for Custom Tags, all Custom Tags and CFCs in that location will be available to all applications on the server.
To have a seperate folder, anywhere you want, to house common/shared CFCs all you need to do is create a mapping in your Application.cfc file and then use that to reference the CFCs and make instances of them.
In Application.cfc do the following:
<cfset this.mappings["/sharedcfc"] = "absolutepath\to\sharedfolder e.g. C:\Code\CFC" />
When you want to use a CFC in your application's code just do this:
<cfset MyCFCInstance = New sharedcfc.folder.nameofcfc() />
You can now have a common area for multi-purpose CFCs to use across your applications. What a life saver!
How to setup a django-cms project to support multiple websites?
There's no reference to this in the official documentation and only limited information in the mailing list, but it's in the headline "A Django application for managing hierarchical pages of content, possibly in multiple languages and/or on multiple sites." and through the Django Sites Framework there's already built in support, and in the admin pages can be associated to different sites.
Related:
Django-CMS: Multiple domains on same project
there are a few different options to manage different websites (and, thus, templates and page contents) in Django-cms.
The basic approach
My favorite is probably the simplest:
In my virtualenv I have a single django-cms installation AND a single "project" that contains ALL the templates I use.
I have a global settings file plus one for each website that does only import all global settings and set "SITE_ID".
from base import *
SITE_ID = XXX
For structure i usually have a settings folder, an empty __init__.py inside, a base.py with all the common settings - including django-cms settings, and then the different websites eg. site1.py site2.py etc. (sometimes my structure is even slightly more complex to also account for dev/production, different machines, etc. but that's not relevant here).
I launch each website as a different instance - I use gunicorn so that's extremely easy too, each one of a different port.
I have an nginx fronted with a separate server configuration for each of my websites, and each of these points to a different gunicorn.
server {
listen 80;
server_name example1.com www.example1.com;
...
location / {
proxy_pass http://localhost:PORT;
}
}
Any of the gunicorn instances can access the admin, and all the data is shared in a single database, but for simplicity
That's all!
Of course it can be done similarly with Apache, mod_wsgi and different virtualhosts.
Advanced
Themes
I actually structured my folders to have an apps folder called themes. Each theme is actually an APP, though mostly contains only the templates and static folders, and it's added to the INSTALLED_APPS.
This allows for cute things such as inheritance and/or overriding between different themes.
Dynamic SITE_ID
It's also possible to use a middleware that will dynamically extract and set the SITE_ID from the URL. This allows to have one single instance... but I don't see any real advantage in this solution and rather find it a potential source of risks.
I'm using fossil to manage some home projects and keeping notes in the wiki. After running like this for a few months, I'd like to at least try to use embedded documentation; mainly so as to be able easily to go back to previous versions.
I've studied the website page about managing project documentation which confirms that this is a technique I want to follow up, but I can't make out how to do it.
I've cut-and-pasted one of my wiki pages and added it to my fossil repo, but I can't work out where it should go in the directory structure to be accessible as described on the above page.
I've tried in a few places none of which worked. The document is currently %fossil-root%\doc\foo.wiki, (I'm on Windows), where %fossil-root% is the directory holding _ _FOSSIL__ (slighly mangled filename because of markdown), but having started a server with fossil ui, when I point my browser at http://localhost:8080/doc/foo.wiki, fossil presents me with a nicely formatted page saying it can't find index.html. I created /doc/index.html to see what would happen, but it made no difference.
Please can someone help me out, and/or point me to an example repository containing embedded documentation or another "how-to" document.
If your document is located in %fossil-root%\doc\foo.wiki, you can access it at the following URL:
http://localhost:8080/doc/trunk/doc/foo.wiki
This URL breaks down as follows:
http://localhost:8080 is the root URL to access Fossil when you run fossil ui
/doc signals that you want to access embedded documentation
/trunk indicates the checkin containing the documentation you wish to access
/doc/foo.wiki is the path of the document inside the repository
Instead of trunk, you can also specify a tag, or a branch name, or even a hexadecimal checkin identifier.
In the URL you were using, http://localhost:8080/doc/foo.wiki, foo.wiki is interpreted as the checkin name, and no document path is specified, which logically means Fossil won't find anything.
As for an example repository containing embedded documentation, the homepage of the Fossil website itself is a prime example:
https://www.fossil-scm.org/index.html/doc/trunk/www/index.wiki
where
https://www.fossil-scm.org/index.html is Fossil's root URL
/doc indicates a request for embedded documentation
/trunk indicates we want to fetch files from the trunk
/www/ is the path to the requested file inside the repository
index.wiki is the name of the file inside the repository.
So, in the 'trunk' branch of the repository, the file www/index.wiki contains the home page of the Fossil website.
You simply need to put the documentation under the %fossil-root%\www\ directory (or any other directory under version control) in your repository and then you can, for example, add the following line to your header's mainmenu section to link to it:
html "<a href='$home/doc/trunk/www/foo.wiki'>Documentation</a>\n"
As I said, it can be any directory under version control. To test this, pick any file in the repository, let's say a README file at the top level, and go to http://localhost:8080/doc/trunk/README. You should see the README file load up in your browser in a raw text format. By putting wiki or html files under a particular directory such as www you make it easy to organize the files that you specifically want rendered as documentation, which makes it easier to link to them.
http://www.fossil-scm.org/index.html/doc/trunk/www/embeddeddoc.wiki
After fossil 1.33, just prepare your document in the repository.
If the wiki file is put in
/doc/index.wiki
And use web browser to setup -> Admin -> Configuration.
There is a "Index Page" field, fill in your main index.html.
For example:
/doc/trunk/doc/index.wiki
Or if you just want the released version:
/doc/<version>/doc/index.wiki