With https://travis-ci.org/, I suggest.

When searching for images, if you enter a query string which will not return resuls you will get the message Sorry, no images match "" (without the query string inside the ""). Beyon this, search works fine.

On the dashboard the "Your most recent edits" can show the same page multiple times if you've edited that single page a lot. For this UI feature to be beneficial it should show only the most recent edit for a page, allowing other pages to appear in the list too.

Post date date-selection widget defaults to writing the date in the following format 14 Feb 2014

The admin won't accept the date unless it's written in 2014-02-14 format.

There appears to be a very well written tutorial on setting up Wagtail here (http://spapas.github.io/2014/02/13/wagtail-tutorial/) but I don't see any "api" documentation. Is there plans to create and and post something like this to ReadTheDocs?

When 'more' navigation links in the left column are exposed there's a display issue on shorter screens.

We want it to be possible to incorporate Wagtail into a Django project at a base URL other than the root, e.g. http://example.com/pages/ . However, the methods for constructing page URLs (Page.full_url, Page.url, Page.relative_url in wagtailcore/models.py) do not take this into account, and just return the path that Wagtail knows about from its tree (/path/to/page/ rather than /pages/path/to/page/).

A quick fix would be to run the generated path through django.core.urlresolvers.reverse so that it picks up any prefix defined in the URL config - however, this wouldn't work for multi-site installations that have Wagtail rooted at different places on different sites. (This would typically be done by setting up a separate wsgi instance for each site, with its own settings module and urlconf, in which case the instance generating the URL may not even be able to see the relevant urlconf.) A more robust approach would be to extend the Site record to define a root path as well as a hostname.

One of the features we really wanted in Mezzanine (but couldn't get) is page revision support. Are there any plans to add this features into Wagtail?

When there is no EMBEDLY_KEY setting in settings.py an exception will be thrown when POSTing to /admin/embeds/chooser/ so pressing the button won't do anything.

The exception is because of line 17 of embeds.py: client = Embedly(key=settings.EMBEDLY_KEY). The best way to handle this is check if there is no EMBEDLY_KEY and show an error message to the user ("Please configure an EMBEDLY_KEY in your settings") similar to the one that is already shown now if the URL is not correct ("This URL is not recognised").

For instance if the title of your page is "ΔΟΚΙΜΗ" the slug field will be empty. If it is "ΔΟΚΙΜΗ 1" the slug field will be "-1". This is because of the cleanForSlug function in wagtail/wagtailadmin/static/wagtailadmin/js/page-editor.js.

Instead of this the django/contrib/admin/static/admin/js/urlify.js tool could be used.

How does Wagtail handle video content? Can you upload a video and have it rendered in an embedded player? What about providing a link to a video on Youtube or Vimeo and having that embedded on the site?

If a repeating object contains a rich text field the hallo editor toolbar appears where it would if the input were not inside a repeating object.

As the Hallo.js toolbar is always appended to the body, not somewhere nearer the input on which it was invoked, there's no way of using CSS inheritance to reposition the toolbar in different situations.

Ideally we should find a way of getting Hallo to append nearer the element or giving it a class which can be used to alter it's position in different situations.

When moving a page the user is provided with a tree menu to choose the destination parent page. The status tag of pages in this appears...

• to have 'None' as an href. Links should be suppressed on this view as they're just a distraction.
• to be invisible once hovered. This seems to just be an error as a result of css specificity and the fact that links ought not to be displayed at all, but rather spans.

https://github.com/torchbox/wagtail/blob/70e91d6759e86a0490b478d7f5ae4dafae8bc663/wagtail/wagtailadmin/taggable.py#L51 implements a workaround to the taggit API to allow us to pull in tags on prefetch_related queries. django-taggit 0.11 introduces proper prefetch_related support, so we should use that instead.

(Note that wagtail/django-modelcluster#1 currently blocks us from upgrading to 0.11)

ref Marc Tamlyn's 'How does Django start?' talk at Django Weekend Cardiff - it sounds like there'll be a fair bit of work involved in making Wagtail compatible with Django 1.7 (while keeping it backwards-compatible with 1.6 for the time being) - moving module code to app startup() methods and avoiding 'for app in INSTALLED APPS'.

Initially by supporting hosted Elasticsearch, eventually by abstracting search to support easier-to-install search backends, e.g. Whoosh or PostgreSQL FTS.

Tried adding a post, saw an error and had no idea what to do. Not until I used pdb to figure out what was going on did I realize the error might be in another tab:

BeautifulSoup (and consequently lxml) is used for whitelisting of HTML elements rich text fields when they're submitted, and as a dependency of django-compressor. Can we avoid lxml installation (which in turn requires libxml2 and libxslt) by specifying html5lib as the parser for BS and django-compressor?

wagtaildemo has a local.py mechanism for changing the db auth info and other settings but what is the recommended mechanism for doing the same with running tests for wagtail? Making a copy of runtests.py and then changing the values in the copy?

If you search for R or Roo or Root etc you will get a 500 exception (probably because it finds the Root page that has no parent):

NoReverseMatch at /admin/pages/search/

The problem is in this line

<td class="parent"><a href="{% url 'wagtailadmin_explore' page.get_parent.id %}">{{ page.get_parent.title }}</a></td>

of

\wagtail\wagtail\wagtailadmin\templates\wagtailadmin\pages\list.html

Hey guys, wondering if you have any advice on where to start on this subject, or if you've done something like this in development of wagtail.

My goal is to generate something on the order of 50k assets: images, pdfs, psds, docs.

Will be happy to share my process and results of course :)

Would be nice to have a place to discuss wagtail things related and ask questions if need be.

If I have understand correctly, a new installation of wagtail will always have a "Welcome to your new Wagtail site!" page as the home page, and the only way for the user to change that is to got to the normal django admin and change the root page for the site.

I find it confusing for the end-user to need to go to the django-admin to change this -- even if it would need to be done just once.

Probably the easiest way to resolve this would be instead of creating the homepage and localhost site in 0002_initial_data.py to provide a management command that would explain to the user what is going to happen and ask the user of the type of the page he wants to have as a homepage (with Page) being the default.

Also, even if the default behavior doesn't change there could be a change_homepage_type management command that would change the homepage for a specific site.

When a page is published but has no reachable URL - e.g. it exists at the root level alongside 'home' and has no Site record pointing to it - we still show a 'View Live' link in page listings, but with an href of "None". We should hide this.

(Ideally we ought to give editors a warning message at the point that they create an un-routeable page, but that needs separate design consideration)

Wagtail should be available in other languages. I'd expect the translations themselves would come from contributors, but the support for languages needs adding.

Since Google AppEngine supports python, I think it would be great to be able to run wagtail on AppEngine.

Inside core.js there is arguably a small amount of jQuery abuse taking place.

Relying on jQuery to add / remove / toggle classes and add event listeners isn't necessary in modern browsers. Without adding polyfils this would drop support for IE9 and below.

The performance increases are going to be minimal but when using the admin on a low powered device it's advantageous to keep things as lean as possible.

I'd be happy to refactor the code.

This is because wagtail\wagtaildocs\templates\wagtaildocs\documents\list.html has a typo. Already fixed in PR #9

There is a CHANGELOG.txt but no releases tagged in git matching the releases.

This approach to installation is interesting: https://github.com/mirumee/saleor

Thoughts?

Tests should be very small, right now wagtailembeds for example check multiple things in a single test.

https://github.com/torchbox/wagtail/blob/master/wagtail/wagtailembeds/tests.py#L10

See:

http://programmers.stackexchange.com/questions/7823/is-it-ok-to-have-multiple-asserts-in-a-single-unit-test

If child objects within the page editor are reordered, and then a validation error occurs when the page is saved, the form is reshown with inline objects rendered in their original (saved) ordering.

Right now a bunch of default tests are being run when the test runner is run. The assertion where 1+1 = 2.

I think you can add a skip there at least if you're looking to keep the files around for testing later so at least the test pass count is accurate.

@skip("Don't want to test")

From an implementer's perspective the tags needed to build a page are a bit muddled.

pageurl is called as {% pageurl %}, image_tags is called as {% image %}, then rich_text is called as the filter |richtext.

The spaces and underscores seem intended to trick me! Can they be made more uniform? And given that a page would rarely be built without images, urls or rich text, could these be loaded as a single tag somehow?

I can add an editor's pick just by defining the search term and without adding any recommended pages. This will display the "Editor's picks for 'dasd' created." however nothing will be visible in the editor's pick list.

Also, if I click on "Add recommended page" and click save immediately without filling any info I will get a 500 error (exception: 'EditorsPickFormSet' object has no attribute 'ordered_forms')

• From an empty Wagtail build, create a page called 'newhome' under the default homepage
• In django-admin, change the default Site record to point to newhome
• Move newhome to the root level
• The url for newhome (as seen in the 'View live' link on the page listing) now shows up as None, because it still has the old location of newhome (home/newhome) cached in wagtail_site_root_paths, and so it thinks that the current path (/newhome) is unrouteable. In this scenario, we should update/clear the cached record when the page is moved.

We should add what is essentially explained in the link below to the instructions on gh-pages. It currently says "Edit code locally", however you cannot edit locally until shared folders are setup.

The instructions are here already:
https://gist.github.com/gasman/8802632

They just need to be explained and put into the readme.

What is the modelcluster for? Is that needed for backend/ui development?

Using the Wagtail Vagrant demo and tested using Chrome 32.0.1700.107, clicking the sort icon and trying to rearrange children pages did not work.

If a 500 error occurs when previewing a page from the edit interface, the JS to insert the response into the newly-opened window simply aborts, leaving the spinner in place. We should push the error response into that window instead.

When I tried editing rich text content from my Nexus table (through google chrome) I observed that if I selected bold or italic I couln't unselect it so it kept writing bold and italic text no matter what (until of course I saved the page).

Possibly with lesscpy, though note the node version is more performant for production.

There is a number of hardcoded urls for /admin in javascript files. They should be removed because the wagtailadmin will break when people map it to a different URL than /admin (and of course for DRY-ness).

Probably a solution like https://github.com/Dimitri-Gnidash/django-js-utils would be the best way to handle this.

This is because of line 251 of wagtail\wagtailcore\models.py:

cursor.execute("""
        UPDATE wagtailcore_page
        SET url_path = %s || substring(url_path from %s)
        WHERE path LIKE %s AND id <> %s
    """, [new_url_path, len(old_url_path) + 1, self.path + '%', self.id]) 

substring is not available in sqlite3 and should be replaced with substr.

If you copy any section of text from wagtail.io (for example) and paste it into a text area, it retains lots of styles you wouldn't want to be copied into your site.

Of course wagtail strips style attribute upon saving but I'd expect most users would probably grimace and try to somehow undo it, fail, and get themselves in a complete mess before thinking of saving.

This example is somewhat contrived, but as we know from users of Word, people paste anything from anywhere without thinking, and why not? If we're to make content entry the experience we want it to be, this needs addressing.

Hello,

I tried installing wagtaildemo using sqlite3 as a backend database.

running python manage.py syncdb works fine, however running python manage.py migrate produces a series of exception. More specifically, I can see the following (I will copy just the important bits):

The first time the exception is because of:

File "..\..\wagtail\wagtail\wagtailcore\migrations\0002_initial_data.py", line 11, in forwards model='page', app_label='wagtailcore', defaults={'name': 'page'})

The second time I run migrate, the exception is because of:

File "..\..\wagtail\wagtail\wagtaildocs\migrations\0002_initial_data.py", line 11, in forwards  model='document', app_label='wagtaildocs', defaults={'name': 'document'})

The third time I run migrate, the exception is because of:

File "..\..\wagtail\wagtail\wagtailimages\migrations\0002_initial_data.py", line 11, in forwards model='image', app_label='wagtailimages', defaults={'name': 'image'})

The fourth time, the migrate completes without problems!

In all cases, the error I see is the following:

- Migration 'wagtailimages:0002_initial_data' is marked for no-dry-run.
! 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.
! You *might* be able to recover with:   (migration cannot be dry-run; cannot discover commands)
! The South developers regret this has happened, and would
! like to gently persuade you to consider a slightly
! easier-to-deal-with DBMS (one that supports DDL transactions)
! NOTE: The error which caused the migration to fail is further up.

followed by a stacktrace (originating from the place I wrote before) and ending with:

"Your database backend doesn't behave properly when "
django.db.transaction.TransactionManagementError: Your database backend doesn't behave properly when autocommit is off. Turn it on before using 'atomic'.

Does anybody know what is happening ? This is very confusing and I believe that it leaves my database in a not so good state :-(

Currently various views in Wagtail admin, such as the homepage and page explorer, are guarded by a simple @login_required decorator. This means that if the site is making use of user accounts on the front end, those users will be able to access Wagtail admin (albeit with no permission to actually do anything).

A quick fix would be to restrict Wagtail admin to users with the is_staff flag set (i.e. use the staff_member_required decorator from django.contrib.admin.views.decorators in place of login_required). However, this isn't always appropriate - student editors on RCA would not have is_staff set, for example. A more thorough solution would be to define a 'can access Wagtail admin' permission (slightly messy, as it isn't attached to a specific model) and add this to our default groups.

We will continue to recommend Redis for production, but Wagtail should fall back e.g. to the standard Django cache framework in development environments.

If you want people to contribute to this, there is no obvious way to run a test suite. This is vital for future development.

Rather confusing, visiting the login screen while already logged in presents the user with a login form again. It should redirect them to the dashboard, I'd suggest.

At present there doesn't exist anything client side as per Apple's best practises (http://bit.ly/1ks4xqF) for supporting retina display resolution. Gravatar profile images and general site image media are not suited to a device pixel ratio of 2.