-
Notifications
You must be signed in to change notification settings - Fork 15
Frequently Asked Questions
We are using Transifex as our translation platform. We have a number of translations in progress now. Please go to our Transifex page at: https://www.transifex.com/projects/p/edx-platform/
When running with the development environment settings, registration emails are not sent out. However, the URL with their activation key is logged to the console. Just copy it from there and paste it into the browser.
To make the registration emails being sent out, change the file edx-platform/cms/envs/common.py the line
EMAIL_BACKEND = 'django.core.mail.backends.console.EmailBackend'
to the line
EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend'
Using Studio, upload an image named images_course_image.jpg
Please read: [Controlling-course-creation-rights]
Modify the server deployment commands to include the IP address, like this: rake cms[dev,0.0.0.0:8001] and rake lms[cms.dev,0.0.0.0:8000].
From a stackoverflow question on 0.0.0.0 in Django,
0.0.0.0:80 is a shortcut meaning "bind to all IP addresses this computer supports". 127.0.0.1:80 makes it bind only to the "lo" or "loopback" interface. If you have just one NIC with just one IP address, you could bind to it explicitly with, say, "192.168.1.1:80" (if 192.168.1.1 was your IP address), or you could list all the IPs your computer responds to, but 0.0.0.0:80 is a shortcut for that.
'Courseware content' is stored in MongoDB and user-data (e.g. user tables, user state, authN, authZ, etc.) are stored in a relational database. For localdev environments, SQLite is used for the relational database to keep dependencies simple, for production environments mysql is used as the relational database. So there's actually really just two rather than three, from that perspective.
In the history of edX, the use of MongoDB as a contentstore is relatively new (previous architectures used XML-based files from the filesystem) and it seemed like a good match since courseware are well modeled as flexible JSON documents. The use of relational datastores for user-data predated the transition of the contentstores and we did not migrate those databases to a NoSQL platform.
CMS and LMS should share the same databases (mysql/RDS for user-data and MongoDB for courseware content) for any deployments. SSO is accomplished by both Django Apps using shared cookies (e.g. *.edx.org, in our case) as well as the same Session database. So if you're deployment is on *.foo.com, then the cookie domain should be set to .foo.com, where the LMS is on www.foo.com and the CMS is on studio.foo.com.
With django-admin syncdb and migrate - is that run both in LMS and CMS or is it sufficient to run once?
Yes, there are no new CMS specific tables in Django, so you should just have to run it once.