No the dropdown still appears against each page, the list of page models is hard coded though. On 16/10/2014 12:54 AM, "Josh Cartmell" <[email protected]> wrote:
> Would this mean that you could now only add custom page types using the > top drop down? > > On Tue, Oct 14, 2014 at 10:13 PM, Stephen McDonald <[email protected]> wrote: > >> That's awesome advice Alex. >> >> I took it a bit further and ripped out more template logic, here's my >> resulting admin template which renders my 1,400 or so pages in roughly 25% >> of the time: >> >> https://gist.github.com/stephenmcd/87a3af5c9a3c66a6c716 >> >> - Removed all permission setting/checking >> - Removed iterating through all the page types and hard-coded the list of >> these (still containing the page_id variable) >> - Removed all use of {% url %} template tag, hard-coding admin urls (this >> is a huge gain) >> - Removed all use of {% static %} template tag, hard-coding paths to >> static assests >> - Removed cycling through CSS classes (I'm not even sure these are used >> anymore) >> >> >> On Wed, Oct 15, 2014 at 12:43 PM, Alexander Hill <[email protected]> >> wrote: >> >>> I've run up against slow page admin rendering too, but nothing as >>> extreme as 90 seconds – more like what Stephen is reporting, under ten >>> seconds. I have a hierarchy with a little over a thousand pages, and I >>> think the maximum depth is five. >>> >>> I found a lot of time was spent rendering >>> templates/pages/menus/admin.html, specifically ascertaining permissions and >>> building the list of models for the "Add..." menu. The majority of my pages >>> are of one type that should only have that same type as children, and >>> everyone should be able to add them, so I've overridden that template to >>> just render a link instead of a drop down "Add..." menu which always adds >>> that page type, instead of iterating over the list of models and checking >>> permissions for each. >>> >>> That cuts down my rendering time by about half. >>> >>> Unfortunately Django templates ARE slow, and rendering a thousand of >>> them nested is never going to be quick. That said, the times you're seeing >>> are extreme and I can't think what would cause that in normal operation, so >>> you probably will need to do some profiling...there is a Django template >>> timings plugin for the Django debug toolbar which might help you: >>> https://github.com/orf/django-debug-toolbar-template-timings >>> >>> Alex >>> >>> On Wednesday, 15 October 2014 00:46:27 UTC+8, Jefferson Heard wrote: >>>> >>>> Stephen, thanks. Would a flatter hierarchy affect things much? It's >>>> not so much the render time as the processing time. I'm getting to 504 >>>> timeouts on the server. I'm running in AWS, with an Amazon postgres and a >>>> medium instance running the web application. I suppose a profiling tool >>>> *is* the next step, but I wondered if anyone else had run into this. >>>> >>>> On Mon, Oct 13, 2014 at 3:55 PM, Stephen McDonald <[email protected]> >>>> wrote: >>>> >>>>> I don't know of one, but I'll just counter one anecdote with another. >>>>> >>>>> I generated 1463 pages evenly spread (11 primary pages, each with 11 >>>>> children, which each have 11 children), and on my macbook air the admin >>>>> interface takes about 6 seconds to render, the front-end which renders a >>>>> full tree as well as some limited trees takes about 3 seconds. >>>>> >>>>> 90 seconds on your machine vs < 10 seconds on a consumer grade laptop >>>>> seems unreasonable. What type of machine are you running on? >>>>> >>>>> You might also like to dig into some profiling tools, like >>>>> django-debug-toolbar and pycallgraph, but be warned adding these will >>>>> certainly make things slower, so don't be deceived. >>>>> >>>>> >>>>> >>>>> On Tue, Oct 14, 2014 at 2:16 AM, Jeff Heard <[email protected]> >>>>> wrote: >>>>> >>>>>> Is there a mod that dynamically loads or paginates the pages section >>>>>> in the admin? I have 1559 pages and I always get a 504 timeout on >>>>>> rendering. When I don’t, it still takes like a minute and a half to >>>>>> render >>>>>> the pages admin menu... >>>>>> >>>>>> -- >>>>>> 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 [email protected]. >>>>>> 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 [email protected]. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- >>> 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 [email protected]. >>> 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 [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > 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 [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
