Esta mañana estaba refactorizando un poco el código de la aplicación de tiendas antes de subirlo al repositorio de un cliente y me he encontrado con el error que describe el título y que me ha traído de cabeza toda la mañana.
Uno de los cambios que estaba haciendo al código era sustituir líneas del tipo:
from tienda.checkout.models import *
por
from checkout.models import *
para mejorar la portabilidad de las aplicaciones, pero a raíz de eso el sitio dejó de funcionar y lo único que recibía era ese mensaje de error.
A la postre resulta que tenía una estructura de directorios y ficheros tal que así:
cart\
__init__.py
admin.py
models.py
cart.py
views.py
checkout\
__init__.py
admin.py
models.py
checkout.py
views.py
etc.
El problema ocurría cuando python interpretaba los ficheros cart.py y checkout.py (entre otros) e intentaba luego buscar modelos en ellos al tener el mismo nombre que el directorio en el que se encuentran.
La solución una vez sabido esto fué sencilla, cambiar los nombres por cart_functions.py y checkout_functions.py a los archivos y en todos aquellos lugares en los que se usaban.
Mientras buscaba en un gran listado de productos desde la administración de django me he topado con el siguiente error:
Related Field has invalid lookup: icontains
A la postre resulta que el problema venía por cómo estaba definida la clase de administración del modelo:
class ProductAdmin(admin.ModelAdmin):
# sets values for how the admin site lists your products
list_display = ('name', 'price', 'brand', 'stock', 'is_pack', 'created_at', 'updated_at',)
...
search_fields = ['name', 'categories', 'brand', 'internal_reference', 'description']
...
Y es que ‘categories’ es una clave externa (ForeignKey) y por eso hay que definir sobre qué campo asociado se buscará, se soluciona, por ejemplo, con:
search_fields = ['name', 'categories__name', 'brand', 'internal_reference', 'description']
Los últimos proyectos en los que estoy trabajando van sobre una plataforma de comercio electrónico.
Como tal, a la hora de mostrar errores a los visitantes/clientes, es importante no desconcertarlos y hacer que pierdan la confianza en el sitio web, por lo cual se personalizan las páginas de error para que se integren en el resto del sitio y además se aprovecha para mostrarle productos que podrían interesarle.
Debido a estos listados de productos no podemos simplemente renderizar un template para los errores, sino que he implementado un manejador para los errores: file_not_found_404 y handler_500. Estos hacían bien su trabajo mientras realizaba el desarrollo en local, sin embargo, cuando se pasaba a pruebas en el entorno de producción todas las páginas estáticas definidas con el framework flatpages direccionaban a la página de error 404.
Después de muchas vueltas, pruebas, desactivar el manejador, revisar logs y volver a probar y a dar vueltas ví que en los logs de acceso las páginas de errores 404 devolvían un status 200 (Ok), lo cual finalmente me dió la pista que necesitaba: tenía que sobreescribir el status_code de la respuesta a 404, ya que por defecto el valor es 200.
El manejador quedó con algo parecido a esto:
def file_not_found_404(request):
page_title = _('Page Not Found')
featured = Product.featured.all()[0:FEATURED_PER_ROW]
bestseller = Product.bestseller.all()[0:BESTSELLER_PER_ROW]
recommended = Product.recommended.all()[0:RECOMMENDED_PER_ROW]
response = render_to_response('404.html', locals(), context_instance=RequestContext(request))
response.status_code = 404
return response
Recientemente he tenido que preparar una plantilla en django que mostrara una serie de imágenes del usuario y un formulario adyacente en el que podían sustituir esta, así que me encontraba con el problema de mostrar al usuario sus fotos actuales, si es que tenían.
Para ello se crea un formulario heredando del modelo:
forms.py:
class PhotosForm(forms.ModelForm):
photo = forms.ImageField(label=_(u'Fotografía'), required=False)
current = forms.CharField(label='', widget=forms.HiddenInput(), required=False)
class Meta:
model = ProfilePhotos
exclude = ('profile','accepted',)
Luego, en la vista, puedes consultar el perfil del usuario en cuestión y ver si tiene fotografías:
views.py
@login_required
def edit_photos(request, template_name='members/photos.html'):
page_title = _(u'Editar fotografías')
PhotosFormSet = formset_factory(PhotosForm, extra=5, max_num=5)
profile = request.user.profiles_set.filter(accepted=True).latest('date')
if request.method == 'POST':
...
else:
profile_photos = profile.profilephotos_set.filter(accepted=True)
if profile_photos:
data = []
for photo in profile_photos:
data.append({'current': photo.photo.name})
formset = PhotosFormSet(initial = data)
else:
formset = PhotosFormSet()
Y finalmente, en la plantilla se puede acceder a los valores de los campos mediante
photos.html:
{{ formset.management_form }}
{% for photos_form in formset.forms %}
{% if photos_form.initial.current %}
[img src="{{photos_form.initial.current }}" alt="" /]
{% else %}
[img src="default.jpg" alt="" /]
{% endif %}
...
Y del mismo modo, se puede acceder mediante form.initial.nombre_clave a cualquier otro dato inicial.
Si en lugar de proporcionar datos iniciales lo que hacemos es asociar el formulario a una instancia ( form.is_bound == True ) entonces podremos acceder a los datos mediante form.data.nombre_clave
Bah, como salta a la vista, el formateo de código de Wordpress no es muy bueno…
De cara a las fiestas Motrilcenter ha lanzado una serie de planes promocionales para facilitar el acceso a sus viviendas en Motril y he estado actualizando la página.
Actualización Diciembre 09 Motrilcenter
Con esto me he dado cuenta de una cosa ¡Aún no le había puesto favicon a la página!