django

Errors in Wagtail templates

AttributeError at /admin/pages/2/

type object 'BlogIndexPage' has no attribute 'related_links'
Exception Type: AttributeError
Exception Value:
type object 'BlogIndexPage' has no attribute 'related_links'

Hmm… something must be off with my templates. I get this error when I try to access my main page from explorer.

When I click ‘View Live’ on my main page from the dashboard I then get:

TemplateDoesNotExist at /test/

wagweb/blog_page.html

 

Request Method: GET
Request URL: http://username.co/test/

TEST is a virtual env directory I found in my cpanel after hosting helped with the installation of lxml in python2.7. It’s strange though, that the request URL is pointing to the TEST virtualenv which is in python2.6

Furthermore, when I try to Save Draft or Publish a Blog_Index_Page I get a wagtail error without traceback:

Picture 9

Advertisements

Unhandled again

oops! I manage to cause an unhandled exception again.

This comes after pip installing Beautiful Soup 4, Beautiful Soup and attempting to install lxml.

A look at ./dispatch.fcgi give the traceback:

File "/home/clarayee/env/lib/python2.7/site-packages/bs4/builder/__init__.py", line 317, in <module>
 from . import _lxml
 File "/home/clarayee/env/lib/python2.7/site-packages/bs4/builder/_lxml.py", line 9, in 
<module>

from lxml import etree
 File "lxml.etree.pyx", line 167, in init lxml.etree (src/lxml/lxml.etree.c:192356)
TypeError: encode() argument 1 must be string without null bytes, not unicode
Content-Type: text/html

 

as suspected! it’s because of the lxml I’ve been messing with.

May be linked to the previous Runtime error with lxml I’ve raised… stay tuned…

RuntimeWarning

RuntimeWarning: compiletime version 2.6 of module ‘lxml.etree’ does not match runtime version 2.7

 

Trying to make sure my bs4 (Beautifulsoup 4) and lxml are properly installed. They are in my system packages but as lxml is installed in python2.6, it does seem like I cannot use it properly with my Python2.7 environment.

Will need hosting to help sort this out for me since I cannot install lxml myself!

 

>>> import bs4
bs4/builder/_lxml.py:9: RuntimeWarning: compiletime version 2.6 of module 'lxml.etree' does not match runtime version 2.7
from lxml import etree
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "bs4/__init__.py", line 30, in <module>
from .builder import builder_registry, ParserRejectedMarkup
File "bs4/builder/__init__.py", line 317, in <module>
from . import _lxml
File "bs4/builder/_lxml.py", line 9, in <module>
from lxml import etree
File "lxml.etree.pyx", line 167, in init lxml.etree (src/lxml/lxml.etree.c:192356)
TypeError: encode() argument 1 must be string without null bytes, not unicode
>>>

INSTALLED_APPS

In the process of removing the AttributeError in my Wagtail admin page, I added ‘django_libsass’ to my INSTALLED_APPS* in settings.py

 

Now I’m in admin and trying to create a basic blog, but bumped against 

FeatureNotFound at /admin/pages/new/wagweb/blogpage/2/

Couldn't find a tree builder with the features you requested: lxml. Do you need to install a parser library?

Wagtail uses their own tree builder called django-treebeard. The app is installed and can be found in my directory within Wagtail >  Vendor. 

Will try to list it under INSTALLED_APPS and see if it works.

Nope it doesn’t work.

*(correction I have removed django_libsass and nothing broke, so I’m leaving it that way to reduce unnecessary fluff)

Migrations

Ain’t no flock of birds.

So if we’ve been following spapas’ tutorial on how to set-up Wagtail, we will also know how to do a syncdb and migrate

Now that my Wagtail dashboard is finally up, I can move on to the next step in the tutorial. Adding a blog page.

Bump! Migration draws up Not Synced (use migrations) on my wagtails and taggit. But running the usual manage.py migrate returns

— nothing to migrate

Solution:

1. Use schemamigrate

2. Wait patiently for changes to catch up?

SCHEMAMIGRATE

This means I’d use South to handle the migration. Like in this answer by running

python manage.py schemamigration --initial wagweb

This returns:

The error was: table "wagweb_blogpage" already exists
 ! Error found during real run of migration! Aborting.
! Since you have a database that does not support running
 ! schema-altering statements in transactions, we have had 
 ! to leave it in an interim state between migrations.

 

This means I shouldn’t be using South for migration in this format since Wagtail is already handling that.

Despite this error, I have now refreshed my Wagtail dashboard again and notice that my blogpage template is indeed in!

Maybe I should use solution #2.

 

IT WORKED!

bimo

 

Can you believe it!

I know I can’t. Every button I press I still hold my breath and half expect the dreaded Error page.

Now I can actually get down to doing the work of my website! HA! I foresee more painful troubleshooting there so this blog lives on.

But for now, beer is on me!

Uninstalling Sass

Following gasman’s advise to uninstall everything sass-related other than django_libsass and libsass, I am now running pip uninstall for compass, gem – sass and sass. 

And running import sass; sass from python manage.py shell after each uninstall.

Uninstalled Compass

<module 'sass' from '/home/clarayee/env/lib/python2.7/site-packages/sass.so'>

Gem Uninstalled Sass

<module 'sass' from '/home/clarayee/env/lib/python2.7/site-packages/sass.so'>

Uninstalled Sass

<module 'sass' from '/home/clarayee/env/lib/python2.7/site-packages/sass.pyc'>

seeing as I have no idea how to uninstall these assorted sass files, I think I will attempt to simply delete them from cpanel.

Picture 2

Good luck!

Opps! That gave me

Unable to apply CompilerFilter (‘django_libsass.SassCompiler’): [Errno 2] No such file or directory

and also

>>> import sass; sass
Traceback (most recent call last):
 File "<console>", line 1, in <module>
ImportError: No module named sass

I guess those were quite important files then. Let me try and put them back in…

OMG!

I wouldn’t believe my eyes:

Picture 3

 

 

Circular Dependency

So is the cause of my

AttributeError at /admin/login/

'module' object has no attribute 'compile'

a circular dependency within the modules?

Thie StackOverflow question shows an example of what you’d do to get :

AttributeError: 'module' object has no attribute 'blahblah'

In this case it was cause by circular dependency or mutual top-level imports. I suppose that’s a bit like causing this to happen within your files, where a calls b which calls a ….:

infinity

Let me try and see if this is what’s happening with my SassCompiler?

import sass
from compressor.filters.base import FilterBase

Sass is on my Path and Python Path (I checked by importing it in Python and then checking my sys.path).

FilterBase can be found in compressor filter’s base.py

class FilterBase(object):

def __init__(self, content, filter_type=None, filename=None, verbose=0):
 self.type = filter_type
 self.content = content
 self.verbose = verbose or settings.COMPRESS_VERBOSE
 self.logger = logger
 self.filename = filename
def input(self, **kwargs):
 raise NotImplementedError
def output(self, **kwargs):
 raise NotImplementedError

from this we see a class field FilterBase and subclass Object.

Q: What are Field Classes?

  • The first class is the Python object that your users will manipulate. They will assign it to the model attribute, they will read from it for displaying purposes, things like that.
  • The second class is the Field subclass. This is the class that knows how to convert your first class back and forth between its permanent storage form and the Python form.

__init__.py

What’s an __init__.py file?

Picture 19

It’s usually empty, though some times there’s some instructions in there that’s too high level for me right now.

Having an __init__.py file tells python to ‘see’ the directory it is in as a python module. Hence all packages (applications) will have an __init__.py file or several ones within each separate module .

Not having it, or having it in the wrong places will most likely throw an Unhandled Exception.

innit

Q: If it’s empty anyway, can I just copy it into different directories?

I tried, and it doesn’t throw an error unless you copied it into a folder that isn’t meant to be a python module. Then you will get an Unhandled Exception shown in your browser.

Q: What about the pyc file that comes with it?

That woozy file __init__.pyc looks like this:

psycsquare

and is for computers to read. You can delete it (sometimes a .pyc file doesn’t update to reflect the changes in the py file and causes trouble), and a new .pyc file will be generated by your friend the computer when it next requires.

 

from django_libsass import SassCompiler

Following on from the Error during Template Rendering, I still have not solved why I get a

Exception Value:
'module' object has no attribute 'compile'

as previous analyzed, I suspect it means sass is not recognized as a module. But having posted the question on StackOverflow, one of the Wagtail guys have replied :

“…Indicates that Django Compressor is trying to run django_libsass.SassCompiler as a shell command, and the script is failing to run.” – This is a red herring. Django-compressor first tries to interpret the string as a python module, and if that fails (as apparently it is doing here), it falls back on treating it as a shell command. It shouldn’t be necessary to install a command-line Sass tool to use Wagtail – the django-libsass library should be handling it entirely on the Python side.” – gasman

Looks like I’m looking at the wrong stuff then!

 

He also commented:

What error message (if any) do you get if you run from django_libsass import SassCompiler within manage.py shell? –  gasman

I went back into shell, ran

python manage.py shell

Python 2.7.6 (default, Nov 11 2013, 18:34:29)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux2
Type “help”, “copyright”, “credits” or “license” for more information.
(InteractiveConsole)
>>> from django_libsass import SassCompiler

Did not get any errors there, which means django_libsass and SassCompiler are both working and the errors lies elsewhere. Will have to go strain my eyes and poke at that riddle.