theonion / betty-cropper Goto Github PK

I guess the infinite scroll plugin needs a 404 returned on the last page in order to show the "end of results" content.

Rounding on image sizes sometimes results in 1px height difference between two images with the same crop. Two items with the same size and crop should be the same height.

Example:
http://i.onionstatic.com/avclub//5015/26/16x9/250.jpg
vs.
http://i.onionstatic.com/avclub//5015/09/16x9/250.jpg

We should have a widget that allows the upload, search and cropping of images.

Made a change to markup within the forloop for image results. On refresh, I'll get this error sometimes:

Assertion failed: (file != (FILE *) NULL), function MagickReadImageFile, file wand/magick-image.c, line 8739.
Abort trap: 6

I'm seeing this every so often and am filing in case it's something more sinister

All views seem to validate & raise Http404 if given ratio_slug doesn't match pre-defined enumerations. Why bother with views at all, if the regex can reject bad request at the route level.

index f14190f..c5e2076 100644
--- a/betty/cropper/urls.py
+++ b/betty/cropper/urls.py
@@ -3,11 +3,11 @@ from django.conf.urls import patterns, url, include
 urlpatterns = patterns('betty.cropper.views',
     url(r'image\.js', "image_js"),
     url(  # noqa
-        r'^(?P<id>\d{5,})/(?P<ratio_slug>[a-z0-9]+)/(?P<width>\d+)\.(?P<extension>(jpg|png))',
+        r'^(?P<id>\d{5,})/(?P<ratio_slug>(original|1x1|2x1|3x1|3x4|4x3|16x9))/(?P<width>\d+)\.(?P<extension>(jpg|png))',
         'redirect_crop'
     ),
     url(  # noqa
-        r'^(?P<id>[0-9/]+)/(?P<ratio_slug>[a-z0-9]+)/(?P<width>\d+)\.(?P<extension>(jpg|png))',
+        r'^(?P<id>[0-9/]+)/(?P<ratio_slug>(original|1x1|2x1|3x1|3x4|4x3|16x9))/(?P<width>\d+)\.(?P<extension>(jpg|png))',
         'crop'
     ),
     url(r'api/', include("betty.cropper.api.urls")),

Better yet, just compile a regex directly from settings

re.compile('(original|{})'.format('|'.join(betty.conf.app.settings.BETTY_RATIOS))

Then reduce

--- a/betty/cropper/views.py
+++ b/betty/cropper/views.py
@@ -56,13 +56,6 @@ def redirect_crop(request, id, ratio_slug, width, extension):

 @cache_control(max_age=300)
 def crop(request, id, ratio_slug, width, extension):
-    if ratio_slug != "original" and ratio_slug not in settings.BETTY_RATIOS:
-        raise Http404
-

We should be self-hosting some type of cropping view, with JCrop, etc already included.

It might be nice to just pass a top-level element to picturefill which would then find subelements to be picturefilled.

We should be saving images to a lossless original version at the MAX_WIDTH setting, so that subsequent crops won't have to crop from a huge original file.

Should recreate this in python—might need a pull request to wand-py.

Should use a sentry style config layout, maybe have a command that will generate an nginx config?

I'd like to put this in the popover! The placeholder for this data is already there, in index.html.

Should probably take a few steps to help prevent this.

1. We should be issuing warnings when we think that there might not be enough free space on a device. This could be based on the number of images/width settings.
2. If a crop is requested at a WIDTH that isn't in the settings, we should return the crop (with proper cache headers), but should not save it to the filesystem.

Should have a number of improvements, like image optimization, responsive image js, etc.

Right now, it looks like we can specify crop widths:

https://github.com/theonion/betty-cropper/blob/master/betty/cropper/models.py#L152
https://github.com/theonion/betty-cropper/blob/master/betty/cropper/urls.py#L10

It'd be nice to have another url endpoint where we can specify a crop height. That would be useful for design scenarios where you want a list of images are the same height.

Maybe max it out at a certain number to encourage users to fill out metadata. 25?

So that ext4 doesn't need the splitting.

When uploading inline images, I'd like to get the format passed back so I can update the markup properly. Right now, the filename is getting returned and I can use the extension to determine if a file is a gif or not, however that's not that great.

Gifs aren't always animated, either. Maybe /api/new should return whether an image is animate or not, too.