Develop Reference

Subdirectory or Subdomain for Django apps within same project?

Yes, it does depends on use cases. My use case is, I have a generic project of which there are 6 apps, all apps share same google auth session. These apps will be scaling up in few months. I went through many posts to understand which one is preferred and how Django deals with it. Django provides Django Subdomain which requires configuring sites framework. Also there are posts suggesting same for subdirectories.
I am running Django > Gunicorn + Supervisor > Nginx. Few posts I followed which directed everything through Nginx. Two of these posts are: one and two.
There is so much disorientation in understanding what suits best for scaling of use case and which configuration needs to be followed ? Should we follow subdomains or subdirectory ? Where to set configuration in urls.py , settings.py or NGINX for all the routing and static files ?
I understand that this is a big concept and won't fit in single answer. It would be helpful if there's any resource link I can go through.
Thank you for your efforts.

How can I copy CMS pages from a development site to a live site?

I've been integrating Django CMS to a Django project that has been in production already for over a year. As part of my development activities, I've converted to CMS pages those pages that used to be static content before I added Django CMS. My development database now contains pages that I would like to copy to the live site rather than require that project staff recreate these pages on the live site.
I have searched the Django CMS documentation but did not find a command for this. I've also searched the issues on github, the questions on SO and the Django CMS google groups. The only thing I've found is this discussion from 3 years ago. The discussion mentions using dumpdata to dump the cms models. I've tried it. The dump contains information about the pages (for instance, who created the page and when) but it does not contain the contents of the pages.
The live site has data that must be preserved. So I cannot perform a database level dump on the development site and restore on the live site, as this would erase or overwrite data that already exists on the live site.
I'm using Django 1.7 and Django CMS 3.1.0.

The discussion you refer to predates the 3.x series. Perhaps doing a dumpdata for the models associated with the cms application was the way to go 3 years ago, but, as you discovered, it does not work now.
I actually recommend trying the following steps on a mirror of your live site first so that any surprises can be taken care of ahead of the real operation. If you run into trouble on the mirror, you can take your time figuring the problem. Once you are ready to modify your live site, before you do anything, you should backup your database. Better safe than sorry. Also, the codebase on the site should be updated to reflect your development version before you try moving data around.
You can use these steps:
Inspect your INSTALLED_APPS setting and make a list of those apps that are CMS plugins and of the applications these plugins depend on. You may need to consult the installation instructions of some of the plugins to recall what depends on what.
Once you have the list you can issue a dumpdata command on your development site with cms and the applications you identified. For my site, I have to do:
python manage.py dumpdata --natural-foreign cms filer \
cmsplugin_filer_file cmsplugin_filer_folder cmsplugin_filer_link \
cmsplugin_filer_image cmsplugin_filer_teaser cmsplugin_filer_video \
easy_thumbnails djangocms_text_ckeditor > data.json
If you also have created custom permission settings for Django CMS, you may need to edit data.json to remove some or all of the custom settings. In my case I had a cms.PageUserGroup instance that I had created on my dev site. It referred to a group that does not exist on the live site and so I had to remove this instance from the data.json dump. Otherwise, the loaddata command in the next step failed with an integrity error.
You then copy data.json to your live site and issue python manage.py loaddata data.json.
If you have any files you've added to your media directory on your development site to create your CMS pages, you also need to copy them over to your live site.
I've used the procedure above to move data from my development site to a live site, with no discernible problem.
Caveats
The procedure above is meant to be a one time deal. It won't work if you continue making changes to your development pages and then try to migrate them over to your live site.
I've mentioned issues with permissions in the steps above. You are least likely to run into permission issues if you have CMS_PERMISSIONS set to False. If set to True, then you may have to edit your dump like instructed above before loading it on the live site. If you've done heavy customization of the permission scheme and have a whole bunch of PageUserGroup instances and a bunch of pages with special permissions, etc., then you are likely to run into major difficulties. I don't know a solution short of undoing all this customization, or editing the dump by hand to make it match your live site. The problem is due to the fact that the procedure above does not dump the authentication models (of django.contrib.auth). If you are in a situation where you can safely load them on the live site, then adding them to the dump would probably do the trick. However, when you have a live site that has been in production and where the authentication data has changed over time, you cannot just load the authentication models from the development site as this would overwrite some of the records (e.g. "admin"'s password would change to the one stored in the development database).
The method above does not move any of the pages' history. It is recorded with reversion. If you wanted to move the page's history, you'd have to add reversion to the list of apps to dump but I'm pretty sure it could have undesirable side-effects: it could also affect the data that reversion records for other apps that use it in the project. (In effect it would change or erase history of other apps.)

To copy CMS pages from a development site to a live site you could use Django CMS Transfer:
https://github.com/django-cms/djangocms-transfer
Django CMS Transfer is a package that allows you to export and import plugin data from a page or a placeholder.
It works pretty well for simple tasks like exporting plugins' content from a page and then importing it to another site.
However, it does not support foreign-key relations and won't import or export related data.
The Django CMS Association endorses this project.

Django correct applications distribution

After reading through How do you divide your project into applications in Django? and Django documentation about applications I am still not sure whether I should make or not a new application for certain stuff.
Let's imagine I have a Website with the following sections: <Home> <Login> <Register> <My account>.
Should all them be different applications? or should they be just one?
Also, imagine I include a section <Wiki> but it is not very linked with the page (I mean, not the design but the content makes relation to it).
Would this be a new project or application?

The individual sets of functionality (such as the ones you listed) should be applications.
When you group several applications together, you form a project.
However, the individual applications are usually self-contained enough that they could be picked up and dropped into another application. In this manner, you can re-use your 'login' application in several projects.

If it's part of the same site or webapp you're building, than don't make another project, one project shares the same settings.py, for example, so you can imagine that everything that relates to it belongs to the same project.
About the apps, you can create an entire project with just one app, but that's not advisable, you can separate your models in apps in a way that you fell confortable with it, for your own organization.
About login/register, take a look on User authentication documentation, that can clarify a little how one part of the site, in this case, authentication, can work with it's own app.
You should also do the Tutorial which could help you to understant how django basically works.

Newbie Django: Creating a project with several apps or all in one

I am begginer in the Django world, I developed some "information sites" (nothing complicated) but this week my boss order me to make a migration of a big software that has 7 modules.
So I went to read the documentation page and search in google for how I could design this software using Django. I know that the every "module" can named as "app", so I create a new project and one app for every module (I dont know if it was right because the modules will not be public).
The problem is that now I don't know what is the next step.
All my apps can share data (every app has its owns models but sometimes one app has a model that was related to the models in other apps)?
Where do I write the code for the login process (I create a manageUsers app that was thinked to handle the registration, edit, share and validate profile of the current or new user ) and we can be able to share this session data accross the apps?
I need one more app for put the website information (like contact, about, pricing ...)? I use Python 2.7, Django 1.3, Memcached and Mysql 5.
If someone can help me or tell me where it may clarify these questions because most explains how to develop using only one app and in the IRC got no reply or else I must be write all the code in one app?
Best Regards

A good place to start (dated, but worth reading; look at user comment bubbles too): http://www.djangobook.com/en/2.0/ . Chapter 1 - 10 are essential reading. You can pick-and-choose to read the remaining chapters, if desired.
Yes, all Django Apps can share data with one another. You make multiple Django Application's, housed under a single Django Project. The Project sets up a common database to use, and each Application creates Models which use said database. App1 can talk to App2 and vice-versa.
Django Project (one) <----->> (many) Django Application
Typically you separate Apps based on common function. User accounts get their own app (see Auth below). Blog postings get another. A Google Maps interface will get another. User subscriptions, another.
For user accounts and login, Django provides the Auth Module. You can have user accounts stored directly in Django, or configure it to talk to something else, like Active Directory. Auth works "pretty good" out of the box, though I personally customized mine a bit to allow 255-character email addresses as usernames (by default, it limits to 40 characters). Chapter 14 in the Django book might be a little easier to read than the official Auth docs. If you do use Auth, you don't have to make your own Django Application, since Auth already is one! You just install it in settings.py and you're golden.
Your Django structure will likely look something like this:
/Project/
__init__.py
manage.py
settings.py
urls.py
App1/
__init__.py
forms.py
models.py
views.py
templates/App1/
template1.html
template2.html
App2/
...
App2 can access the data-models of App1 by doing: from Project.App1.models import someModel

For me, rules are simple.
If you need to copy-paste some code from one project to another - make an app for it
If one of app's modules code is bigger than 1k lines and/or hard to maintain - look for something to move in separate app
Group functionality into apps to minimize cross-linking between them
For interconnection you can use signals and sessions

Managing subdomains

What are the best practices and solutions for managing dynamic subdomains in different technologies and frameworks? I am searching for something to implement in my Django project but those solutions that I saw, don't work. I also tried to use Apache rewrite mod to send requests from subdomain.domain.com to domain.com/subdomain but couldn't realize how to do it with Django.
UPDATE: What I need is to create virtual subdomains for my main domain using usernames from the site. So, if I have a new registered user that is called jack, when I go to jack.domain.com, it would operate make some operations. Like if I just went to domain.com/users/jack. But I don't want to create an actual subdomain for each user.

You may be able to do what you need with apache mod_rewrite.
Obviously I didn't read the question clearly enough.
As for how to do it in django: you could have some middleware that looks at the server name, and redirects according to that (or even sets a variable). You can't do it with the bare url routing system, as that only has path information, not hostname info.