I have Multiple apps, but every app has it's own template with it's own static files , they server one purpose with different kinds of user and uses. the apps are:
1. Portal
2. Portal Blog editor(Its like an admin panel for the writer with analytics and stuff)
3. Main Admin Panel(Not the django one)
I am using django 2.2 since I am running Djongo.
Please suggest me some solution on this problem along with how do i manage it's urls.
Django supports per-app templates and statics directories.
1/ In each app, create a templates/yourappname and a static/yourappname directory.
2/ make sure you have "APP_DIRS": True in your settings.TEMPLATES
3/ make sure you have 'django.contrib.staticfiles.finders.AppDirectoriesFinder' in you settings.STATICFILES_FINDERS
4/ Then in your code always refer to your templates and static with the matching appname prefix ie appname/templatename.ext and static/appname/filename.ext
Related
I have an Ektron multi-site installation and would like to split one of the sites into a separate installation. Any ideas on how to do this?
I have made a new CMS400 website. But do not know how to export the data from the multi-site and import it to the new database e.g
Page Layouts
Smart Form Configurations
Library Content
HTML Content
Any Assets
And anything else I have left out that you think is important.
NOTE : Both websites are Ektron 8.6
Setup an esync relationship between the current database and a minsite install database, then use the esync function to do a manual sync of the folder for the site you want to copy.
We have a product which is developed using SharePoint foundation 2010. We are hosting on port 80 and which was stand alone installation of the MSF 2010. Now i need to deploy the same product on different ports for different clients in the farm environment.Right now i am facing some challenges as follows:
we have css, images, jquery files which are mapped to 14 hive folders. Since we were deploying in standalone environment, entire 14 hive folders were serving for one client. Now challenge is, how to manage these css, jquery, images folders in 14 hive folder for different clients(different web applications). If i do small change in one js file(test.js) for one particular file, it should affect for that client itself. It should not affect on other client's js(test.js) file.
Since we are having only one wsp solution, and we need to add this to solution repository. Since sharepoint allows only solutions whose names and GUID are unique. So, if i do some change in one solution for particular client , when i upload it to solution repository , it will not allow, since old wsp is already existing. So, how to manage wsp to serve for multiple clients ? . if i do changes for one client, it should not affect on other clients.
please let me know the best practice for this.
Given that a feature can be activated and deactivated at a SPSite or SPWeb level, there could be a more elegant solution to this situation.
Instead of packaging your images, CSS and JS files to be deployed to the 14 Hive, you could actually have them deploy to a new Document Library that your feature creates in the SPSite/SPWeb when your feature is activated. You can also configure your WSP such that the JS, CSS and Image files get uploaded to the document library so created.
This way one of your problems is solved wherein you can modify the files for one client manually directly through the document library and it won't affect other websites/clients.
Also, in this configuration, your single WSP will be sufficient and should not conflict since you won't be deploying a whole new WSP when you change some code for just one client.
I found this blogpost that shows you how to achieve the above: http://jcapka.blogspot.com/2011/05/deploying-document-library-including.html
I also would recommend this series to know more about different options of packaging things to your WSP: http://blogit.create.pt/blogs/andrevala/archive/2007/12/02/SharePoint-2007-Deployment_3A00_-Overview.aspx
Its written for SharePoint 2007 but most of it hasn't changed in 2010.
If there are any challenges in the above approach, you can probably find workarounds for it.
When you deploy solutions to SharePoint 2010, they are generally packaged as WSP, which are generally named as business area.
If you are using Visual Studio, Open "View -> Other Windows -> Package Explorer" to explore contents of WSP.
So if your clients have different html, css, javascript, consider packaging them in different WSPs.
One solution per client
This way under 14 hive, each solution (WSP) items will be contained in their respective folders, which means changes in css of one solution won't affect other solutions.
If you have application pages, they can go:
14\TEMPLATE\LAYOUTS\Client_1\
14\TEMPLATE\LAYOUTS\Client_1\css
14\TEMPLATE\LAYOUTS\Client_1\javascript
14\TEMPLATE\LAYOUTS\Client_2\
14\TEMPLATE\LAYOUTS\Client_2\css
14\TEMPLATE\LAYOUTS\Client_2\javascript
14\TEMPLATE\LAYOUTS\Client_3\
14\TEMPLATE\LAYOUTS\Client_3\css
14\TEMPLATE\LAYOUTS\Client_3\javascript
If you have client specific webparts, they can go:
14\TEMPLATE\CONTROLTEMPLATES\Client_1\Webpart1
14\TEMPLATE\CONTROLTEMPLATES\Client_2\Webpart1
14\TEMPLATE\CONTROLTEMPLATES\Client_3\Webpart1
All you need is to create well defined directory structure in your WSPs.
I've got a DotNetNuke system (v 5.6) that's hosting several different portals, and I'd like to move one of them to another hosting provider. What's the easiest way to do this?
Every web site I find that claims to explain how to move a DotNetNuke site essentially says "Copy the entire database over to the new system." That's great if you've only got one portal in the database, but I've got a dozen of them. I only want to move one portal, not all of them.
Exporting the site to a .template is another popular suggestion. This exports the structure of the site (all the tab definitions, for example), but it doesn't include any of the actual HTML content. As such, that's essentially worthless.
There must be a reasonable way to do this short of trying to strip one individual portals data out of every single DNN table. Right?
When you export a site template, you can include the content of the site, as well (for the modules that support portability, which includes the standard HTML module). This is how the default site template has all of its content. When you do this, there will be a .template.resources file that you'll need, as well as the .template file.
The other option is to do a full backup and restore, and then remove the other sites once you've restored. If you have significant content in a module that doesn't support portability, I think this will be your best bet.
FYI, I did find a solution from someone over on the DotNetNuke forums.
Create a 2nd version of that install, then delete all the other
portals. Move the install with the one portal. We've done this several
times with installs with lots of portals and it works just fine. Yeah
there's still some noise left in the db, but it's a quick and
effective way of doing things.
Edit note that this will give you an install with 1 portal. You can't detach a portal from one install and reattach it to an existing
install (well, you can, but basically you have to export the portal as
a template and that isn't 100%)
This is the approach I took, and sure enough, it works.
In a nutshell:
Mirror the files for the web site to another server.
Mirror the DNN database to another server.
Log in a Host on the new setup and delete all the portals but the one you want to migrate.
Delete any module definitions that are not in use by the remaining portal.
Open up your favorite SQL tool and delete any entries in the Users and UserProfile tables that no longer have a matching row in the UserPortals table. DNN does not remove these by default, which is frustrating.
Hop in to Windows Explorer and delete all of the Portal folders you no longer need (ie: /Portal/1, /Portal/2, etc.)
Back up the database using Enterprise Manager to create a .bak file
Make a .zip of the entire DNN installation folder.
You now have a .bak that contains the database and a .zip that contains the files. Send those off to the new hosting company, and you should be all set. Just make sure to update your web.config to set the connection string properly to point to the new database server at the new hosting company.
It's just that easy. ;)
I'm sorry for such a complex subject. My problem is.
I tried to move my Drupal 7 site from one server to another.
I uploaded a fresh install to my new site.
I backed up my old database and imported to my new site.
I uploaded settings.php file to my new site.
When i entered to my new site's module part, All the 3rd party modules i installed in my old site, exist in my new site without any loss :)
But when i check the folders
/sites/all/modules
/sites/default
/modules
I couldn't find any file regarding to this modules.
Modules exist in my new site when i check my admin panel, I can create content by using this modules, But i can't see their files by using file manager etc.
Thank you
Because you didn't disable the modules before moving your deployment, I think they're still marked in your database, same for registration of content types. As the modules don't actually exist, you won't get their functionality.
Replacing the modules under /sites/all/modules or /sites/default/modules should leave them working as before.
What is the purpose of datasync project in weblogic project?
What is *.evt, *.req, *.usr files?
There is a good explanation on the docs about datasync. Basically it is a webapp used to copy data across from one weblogic server instance (actually from it's database) to another. Example - copying all the data from production to test instances.
*.evt, *.req, *.usr files are XML format files used in Weblogic Portal applications.
EVT files are event files which can be triggered at any user interaction with the Portal. This is mainly used for capturing user behaviour and firing any rules, an example is a
campaign fired for specific users.
REQ files define the HttpRequest attributes
USR files define UserProfile attributes