I have an openedx instance which works fine with just an strange issue. for those who aren't familiar with openedx it's a learning management system written in django.
The issue:
trying to access django admin from http://mydomain.tld/admin shows the login page properly but with two static files, unfortunately one of them (base.f4e3330c1326.css) is not on the file system and the request for its loading ends with a HTTP 404 Not Found response.
looking at the static directory, there are 3 related files:
├── base.5af66c1b1797.css
├── base.css
├── base.d01c565630c2.css
caclulating the base.css md5 checksum:
user#host: ~$ md5sum /edx/var/edxapp/staticfiles/studio/admin/css/base.css
5af66c1b1797cb8f865b443cea0dcc17 /edx/var/edxapp/staticfiles/studio/admin/css/base.css
using django shell to retrive the path to the files:
>>> from django.contrib.staticfiles.templatetags.staticfiles import static
>>> static('admin/css/base.css')
'/static/studio/admin/css/base.f4e3330c1326.css'
I have collected static files more than ten times but it doesn't fixed.
my similar instance somewhere else has not this problem and I'm realy confused with it. could you please help me to debug this?
PS: I don't know about webpack but I think they started to use it recently and I think it should have some relation to my issue...
Related
I have this app built with flask and now i'm trying to run it on my phone with phonegap.
Although the way i have it organized originally with flask is something like this:
/project
run-dev.py
config.py
/phonegapfolder
/app
user.py
forms.py
views.py
__init__.py
/templates
index.html
My problem comes from the fact that phonegap demands its main html to be the one in
/phonegapfolder/www/index.html
Of course it's useless to just copy my index.html from one folder from another, because we will not find the python files that lie within the app folder.
You best solution would be to use flask on a backend (remote) server and have the PhoneGap application make server requests to the flask server.
PhoneGap projects require that the index.html be set within the application (www) folder.
This post on Reddit might be able to clarify some of the details.
I'm trying to upload my Flask application to AWS however I receive an error on doing so:
Your WSGIPath refers to a file that does not exist.
After doing some digging online I found that in the .ebextensions folder, I should specify the path. There was not a .ebextensions folder so I created one and added the following code to a file named settings.config:
option_settings:
"aws:elasticbeanstalk:container:python":
WSGIPath: project/application.py
the WSGIPath is the correct path to the application.py file so I'm not sure what raises this error. Am I changing the WSGIPath right, is there a better way or is there an issue with something else which causes this to happen? Thanks.
There's a lot of configuration issues that can arise with Flask deployed on AWS. I was running into a similar issue as you, so I can at least show you what I did to resolve the WSGI error.
First, apparently you can do this without the .ebextensions folder (see this post here. and look at davetw12's answer. However, be aware that while this works, I'm not entirely sure that davetw12's conclusion about .ebextensions is correct, based on some of the comments below). Instead, (in the Terminal), I navigated to my project at the same level as my .elasticbeanstalk directory and used the command eb config. This will open up a list of options you can set to configure your beanstalk application. Go down through the options until you find the WSGI path. I notice you have yours set to project/application.py, however, this should not include the folder reference, just application.py. Here is how it looks on my Mac in the terminal (WSGI path is near the bottom).
Note that once you get that set, EB will probably redeploy. That's fine. Let it.
Once you get that set, go into your application.py file and make sure you call your app application. For example, mine looks like this:
from flask import Flask
from flask import render_template
application = Flask(__name__)
#application.route('/')
#application.route('/index')
def index():
return render_template('index.html',
title='Home')
This took away the WSGI path error - although I still had to fix some other issues following this :-) But that is a different set of questions.
If anyone here is doing via AWS Console (GUI), modify the configuration and put your script name in WSGIPath as below.
I'm giving bonus hints if you are newer.
You should match the script name and the Flask object too.
Common mistake: When you're compressing the source code, you need to
select the files and compress, not the folder. (make sure you have the
.py in the root of the zip)
from flask import Flask
application = Flask(__name__)
#application.route("/")
def hello():
return "Hello"
if __name__ == "__main__":
application.run()
I had the same message, but for a very stupid reason.
Apparently, when I cloned the repo to my Windows PC and then pushed back the changes, somewhere along the way Windows changed ".ebextensions" folder to "ebextensions" (dropping the leading ".").
So when I renamed back the folder to ".ebextensions" in the master repo, everything started working again perfectly.
For me the problem was I had misspelled a filename:
I wrote: ..ebextensions/django.conf
When I needed: ..ebextensions/django.config
This cost me about 3 hours of my life today. The trouble was that the AWS error is misleading, because the "WSGIPath" it refers to is not the file above, but some invisible default.
In my case trying many solutions didn't solve the issue but changing WSGIPath from
option_settings:
"aws:elasticbeanstalk:container:python":
WSGIPath: project_name/application_name.py
to
option_settings:
"aws:elasticbeanstalk:container:python":
WSGIPath: project_name.wsgi
worked like a charm. Here is the file structure:
├── manage.py
├── mysite ***
│ ├── __init__.py
│ ├── settings.py
│ ├── urls.py
│ └── wsgi.py ***
├── myvenv
│ └── ...
└── requirements.txt
I was having a problem that the django test runner wasn't finding the tests for my app, like this one:
Django test runner not finding tests
One of the comments on that thread suggested creating a new app with django-admin.py and seeing if the tests ran there. e.g.
django-admin.py startapp delme
then
adding "delme" to my INSTALLED_APPS
then
copying my tests.py from the app where it wasn't getting found into delme/
and viola! the tests did run. So, OK, I have a work arround, but I don't understand. I re-read what I think should be the relevant parts of the django documentation but the penny refuses to drop.
BTW, the app works via runserver and wsgi, so there doesn't appear to be any gross configuration problem. And my tests all pass from their new home, so I obviously need more tests :)
Specifically, I'm running django in a virtualenv, so I had run "django-admin.py startapp" in the (activated) virtualenv where I wanted the tests to run. This doesn't make the tests run in my other virtualenvs, I still have the old symptoms there (Ran 0 tests). I have a multitude of virtualenvs, managed by non-trivial paver scripts. One uses "path.copytree" for deploying projects, rewrites apache config files, restarts apache, writes wsgi files using the appropriate virtualenv, etc. The other uses PIP/GCC/aptitude/etc for bootstrapping/tearing down the different environments, updating packages as per configuration, etc. So I want to understand the difference between django-startapp and simply copying files, so I can fix these paver scripts so the tests can run in any environment I want them to.
The only thing that makes sense to me, after reading your description, is the location of paths for your existing apps. Can you confirm the following things:
Your app is at the same folder level as the delme app
Your app folder contains an __init__.py file
Your app is listed in the INSTALLED_APPS setting
I'm going to guess that it's a missing __init__.py file, as that trips some people up. To answer your specific question, django-admin startapp doesn't do anything magical. It just creates the right folders and files in the correct place.
Your folder structure should be...
my_project/
__init__.py
manage.py
settings.py
my_app/
__init__.py
tests.py
models.py
delme/
__init__.py
tests.py
models.py
Also note this comment
You can't easily name the TestCase class directly. You name the app, the Django runner does it's discovery thing by looking in models.py and tests.py
solved (still with a little whiff of magic).
diff showed that my old app didn't have a models.py but the new app ("delme", working) did. I didn't think the old app needed one, it was importing all it's domain classes from other places.
Touching an empty models.py in my old app fixed it, now the test runner finds the tests.py and everything works as expected. Condlusion - if an app has no models.py, the django test runner won't find the app's tests.py.
What I said about not working in different virtualenvs was bogus (red herring), I was a bit confused about what my deploy scripts were doing.
I’m having a problem when using django custom commands on Heroku.
On my local machine, the custom command appears in help if I run ./manage.py help and running ./manage.py deletedphotos runs it too.
All the init.py files are there and the settings are also correct, i.e. there are not major config differences between my local and Heroku instances.
Now, when I put it on Heroku, it does not show up. All my other non-default commands are there: ping_google that comes from installing sitemap.xml support and commands for south migrations. But for some reason, my self written commands do not show up.
I’ve also sent a support request to Heroku, but haven’t heard back from them in a few days, so I thought I’d post here as well, maybe someone has had any similar problems.
The deletedphotos.py file contents are pretty much like this if that matters anything:
from django.core.management.base import BaseCommand, CommandError
from foo.app.models import *
class Command(BaseCommand):
help = 'Delete photos from S3'
def handle(self, *args, **options):
deleted_photos = Photo.objects.filter(deleted=True).exclude(large='', small='', thumb='')
self.stdout.write('Found %s photos\n' % str(len(deleted_photos)))
I’ve tried checking all the correct python paths etc, but not 100% if I’m not missing something obvious.
I was actually able to find a solution. The INSTALLED_APPS had my local app referenced, but for some reason it was not working as intended.
My app is in: /name/appname/ and having 'name.appname' in INSTALLED_APPS was working fine in local setup.
Yet, on Heroku, I had to change the reference to just 'appname' in INSTALLED_APPS and all started working magically.
Your home directory needs to be on your Python path. A quick and unobtrusive way to accomplish that is to add it to the PYTHONPATH environment variable (which is generally /app on the Heroku Cedar stack).
Add it via the heroku config command:
$ heroku config:add PYTHONPATH=/app
That should do it! For more details:
http://tomatohater.com/2012/01/17/custom-django-management-commands-on-heroku/
I had this problem too, found the answer here: Django Management Command ImportError
I was missing an __init__.py file in my management folder. After adding it everything worked fine.
Example:
qsl/
__init__.py
models.py
management/
__init__.py
commands/
__init__.py
news.py
jobs/
__init__.py
news.py
tests.py
views.py
im using django 1.2 and I am trying to deploy django using apache mod_wsgi.
My app works fine using the development server, but when I try to use the wsgi, it can not load file containing template filters.
I have it in structure like /app/subapp/templatetags/core_filters.py, init.py is located where it is supposed to. When I try to open any view loading the code, or template loading {% load core_filters %} exception occurs. It says it is not a valid tag library, at lists all the apps it tried to find core_filters in, but my app.core.templatetags.core_filters is not among them although it is listed in installed apps.
Any suggestions, sollutions?
Any chance you accidentally left your local_settings.py file on the live server, causing some pathing issues or there's some other difference between your settings.py and local_settings.py files?
There was an error on the python path. uWsgi had different python path that contained another package with the same name