[mezzanine-users] Re: s3 and Bad Request 400 + thumbnails with s3

[Lee H.]

There is one other simpler way to get this working

MEDIA_ROOT = ''# stops django throwing bad request 400 in admin 
when looking at blogpost detail
   
then thumbnails will attempt to temporarily write to the local filesystem 
in the dir 'uploads' relative the point of execuation, so if you get 
permissions errors, you need to find what this dir is.
I added a `print os.getcwd()` and found out that the dir was 
`home/djangoUser`. I added the allowed permissions on this dir so uploads 
can be created and written too (my apache is running in daemon mode as 
'djangoUser'). I guess normally it might be www-data, and /var/www or 
something.

So this kinda of fixes this issue for me. I'd still really like to know why 
the bad request is thrown in admin when MEDIA_ROOT is anything other than 
'' or undefined however when using s3.

-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mezzanine-users] Re: s3 and Bad Request 400 + thumbnails with s3

[Lee H.]

>
> ###
> ###  STORAGE ##
> ###
>
> # The custom storage just allows definition of different 'locations' 
so media goes in media/ static goes in /static
# within the bucket. Otherwise same as S3 boto storage. 

>
> # Bucket and creds
> AWS_STORAGE_BUCKET_NAME =  '..'
> AWS_ACCESS_KEY_ID = ''
> AWS_SECRET_ACCESS_KEY = '...'
>
>
> AWS_PRELOAD_METADATA = True
> AWS_QUERYSTRING_AUTH = False
> AWS_S3_CUSTOM_DOMAIN = '%s.s3.amazonaws.com' % AWS_STORAGE_BUCKET_NAME
>
> # Static storage
> STATICFILES_LOCATION = 'static'
> STATICFILES_STORAGE = 'custom_storages.StaticStorage'
> STATIC_ROOT = os.path.join(PROJECT_ROOT, 'temp_static/')
> STATIC_URL = "https://%s/%s/"; % (AWS_S3_CUSTOM_DOMAIN, 
> STATICFILES_LOCATION)
> ADMIN_MEDIA_PREFIX = STATIC_URL + 'grappelli/'
>
>
> # Media storage
> MEDIAFILES_LOCATION = 'media'
> MEDIA_URL = "https://%s/%s/"; % (AWS_S3_CUSTOM_DOMAIN, MEDIAFILES_LOCATION)
> #MEDIA_ROOT = os.path.join(PROJECT_ROOT, 'temp_media')  # bad request 400 
> in admin unless commented out
> DEFAULT_FILE_STORAGE = 'custom_storages.MediaStorage'
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mezzanine-users] s3 and Bad Request 400 + thumbnails with s3

[Lee H.]

I have something of a dilemma. On my production server I get the infinitely 
unhelpful message of "Bad Request (400)", whenever I try to access the 
detail of a BlogPost in the admin.
This occurs wether DEBUG is True/False. It doesn't occur when viewing a 
BlogPost on the regular site, whether logged in or not, and *interestingly* 
doesn't occur when editing the BlogPost richtext content inline on the site 
itself, *just in the admin, *which to me is surprising.

I find that if I omit "MEDIA_ROOT" from the settings (after all it's 
redundant for s3 storage I believe), the mysterious 400 goes away, however 
it it replaced by another error originating from the mezzanine thumbnail 
tag. This error is "Permission denied: uploads", and comes from the 
Mezzanine thumbnail tag trying to write to local filesystem, when it does 

os.makedirs(thumb_dir)

,

 before it pushes up to s3.


*There are two issues here:*

1) The thumbnails tag shouldn't really be writing to local filestystem 
storage at all when using s3. This wouldn't be a massive problem for me 
with my hosting, but could be a major stopping point on something like 
heroku.  There was talk of this issue in mezzanine/issues/530 
; the solution 
presented in the thread seems only partial to me (i.e. it stops the writing 
of image file to disk, later in the thumbnail code, but what about the 
earlier attempts to mkdir etc). It as stated as merged, but I do not see 
the code their even in the Mezzanine master branch on github? (where is the  
InMemoryUploadedFile code in thumbnail now for example?). 

2) If MEDIA_ROOT is required by thumbnail, then it seems Django will 
continue to raise these mysterious 400 responses. My hunch is that it is 
due to Django trying to prevent uploads to a directory outside the 
MEDIA_ROOT when MEDIA_ROOT is defined. Thus, when MEDIA_ROOT is some local 
filesystem path, uploads to s3 perhaps trigger the bad request. Although 
I'm not sure why it would be triggeered just browsing the admin change form 
for a BlogPost, so perhaps I'm wrong.  I started to think along these lines 
because of this django ticket . 
It has now being fixed however, and I verified with a few debug prints in 
the `_os.safe_join` that this wasn't exactly the source of my bad request 
error anwyway.

*A terrible fix:*

One way to hack this bad request into submission is to omit MEDIA_ROOT 
entirely from settings.py (this prevents Django getting tripped), whilst 
also editing the Mezzanine thumbnail source directly:
 
 #mezzanine/core/templatetags/mezzanine_tags.py  thumbnail
 -thumb_dir = os.path.join(settings.MEDIA_ROOT, image_dir,
 -   settings.THUMBNAILS_DIR_NAME, 
image_name)
 +MROOT = '/path/to/some/dir/on/your/server/with/correct/perms/'
 +thumb_dir = os.path.join(MROOT, image_dir,
 + 
 settings.THUMBNAILS_DIR_NAME, image_name)

With this change, thumnails get written into the MROOT directory before 
being pushed to s3, and because of the lack of MEDIA_ROOT being defined 
Django doesn't cry,for whatever reason, in the admin.

I'm not suggesting this as a real fix btw, just illustrating how this fixes 
matters, and hence shows what must be at fault. An even simpler "fix" is 
just adding "return image_url" at the top of the thumbnail code, but of 
course then the thumbnail tag no longer works.

*How to debug the 400 further?*

I'm really at a loss on how to debug the 400 further. I turned on logging, 
and if I do `logger.error('some error')` in the django src I can see the 
errors in my apache logs, but I see no further info on what caused the 400. 
Heck, even if I run the runserver like `python manage.py runserver 
0.0.0.0:80` then connect to that directly from the web, I don't get any 
extra info from the runserver. This error is hard to trace. I tried also 
adding some logs in the django admin change_view src, just to see how many 
the flow of the program goes, but it seems TemplateResponse is just 
returned, and I don't know where to look after that. 


-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mezzanine-users] Re: Slow page load of Python 3 Mezzanine site on Webfaction

[Asif Saifuddin]

best way to deploy django/mezzanine projects is using a vps with nginx + 
gunicorn/uWsgi

On Thursday, June 18, 2015 at 1:53:25 AM UTC+6, xnx wrote:
>
> I'm having problems with my mezzanine site which is periodically very slow 
> to load (TTFB up to 25 secs, sometimes). This usually happens immediately 
> after restarting Apache, but also after a few hours' inactivity. The time 
> seems to be spent waiting for the server to respond with the HTML: the 
> static files (served by a separate nginx server) all come back quickly.
>
> I've tried WSGIImportScript in my httpd.conf and running mod_wsgi in 
> daemon mode as suggested in various places but to no avail.
>
> I've also tried some of the debugging techniques described at 
> https://code.google.com/p/modwsgi/wiki/DebuggingTechniques but because 
> many of them are incompatible with Python 3, they don't help too much 
> either.
>
> Webfaction's support don't seem to know how to help either.
>
> I'm using PostgreSQL as my database backend if that makes a difference.
> Does anyone with experience of running Mezzanine with Python 3 have any 
> advice to give?
>
> Cheers,
> Christian
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mezzanine-users] Re: TinyMCE 4

[Asif Saifuddin]

awesome! template based form rendering in the list?

On Saturday, June 27, 2015 at 4:21:32 AM UTC+6, Stephen McDonald wrote:
>
> Hi all,
>
> I've just merged into Mezzanine the work Alex Hill has done on upgrading 
> TinyMCE to version 4 - it looks a lot better!
>
> Please help out by grabbing the latest dev branch and testing it. I've 
> already ironed out a handful of issues, and AFAICT it works really well.
>
> This should be the last of a many new features that will make up the next 
> release, Mezzanine 4.0!
>
>
> -- 
> Stephen McDonald
> http://jupo.org
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [mezzanine-users] tinymce and django compressor?

[Stephen McDonald]

If you're using the released version of Mezzanine, see if the latest
development branch incidentally solves this - it's using a newer version of
TinyMCE as of yesterday.

On Sun, Jun 28, 2015 at 5:02 PM, Lee H.  wrote:

> I find that if I put the `{% include "includes/footer_scripts.html" %}`
> within the django-compressor `{% compress js %}` block, I get quite a few
> 404s.
> These are for plugins that tinymce wants to use, e.g.
> `plugins/fullscreen/editor_plugin.js`.
>
> The problem seems to be that with compression on the tinymce script looks
> for the plugin relative to whatever the current page is;
> for example `
> http://www.mysite.com/blog/myblogpost//plugins/fullscreen/editor_plugin.js`
> ,
> and not relative to the tinymce script itself.
>
> I can also see in the javascript cmd console that `tinyMCE.baseURL` is
> "http://www.mysite.com/blog/myblogpost/"; with compression on, whereas
> without including it within the compress block the
> `tinyMCE.baseURL` is ""
> https://mybucket.s3.amazonaws.com/static/grappelli/tinymce/jscripts/tiny_mce";,
> as it should be.
>
> 
>
> I can obviously fix this by taking the `{% include
> "includes/footer_scripts.html" %}`, outside the {% compress %} block,
> but then I probably lose the benefits of compression for these scripts.
> Any other ideas? I'm not quite sure how the tinymce js
> determines the base URL or moving the script to CACHE through compressor
> is causing the baseURL to change to the current
> page of my site (I wouldn't have been surprised if it changed the baseURL
> to the CACHE of static root)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Mezzanine Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mezzanine-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Stephen McDonald
http://jupo.org

-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mezzanine-users] tinymce and django compressor?

[Lee H.]

I find that if I put the `{% include "includes/footer_scripts.html" %}` 
within the django-compressor `{% compress js %}` block, I get quite a few 
404s.
These are for plugins that tinymce wants to use, e.g. 
`plugins/fullscreen/editor_plugin.js`. 

The problem seems to be that with compression on the tinymce script looks 
for the plugin relative to whatever the current page is;
for example 
`http://www.mysite.com/blog/myblogpost//plugins/fullscreen/editor_plugin.js`, 
and not relative to the tinymce script itself.

I can also see in the javascript cmd console that `tinyMCE.baseURL` is
"http://www.mysite.com/blog/myblogpost/"; with compression on, whereas 
without including it within the compress block the 
`tinyMCE.baseURL` is 
""https://mybucket.s3.amazonaws.com/static/grappelli/tinymce/jscripts/tiny_mce";,
 
as it should be.



I can obviously fix this by taking the `{% include 
"includes/footer_scripts.html" %}`, outside the {% compress %} block,
but then I probably lose the benefits of compression for these scripts. Any 
other ideas? I'm not quite sure how the tinymce js 
determines the base URL or moving the script to CACHE through compressor is 
causing the baseURL to change to the current
page of my site (I wouldn't have been surprised if it changed the baseURL 
to the CACHE of static root)

-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.