kongondo

No worries...I was just about to post to ask for clarification (i.e. in cases where there are lots of headers to include).... OK, just to get this straight... You have 25 different headers? You do not wish to use 25 different xxxx.inc files What are the differences between the headers? Markup or content (text)? I ask because there are different approaches. This could either be done template file-side or pages-side. E.g. different header content could be stored as pages and rendered as headers. This topic might also be of interest: https://processwire.com/talk/topic/740-a-different-way-of-using-templates-delegate-approach/

Not sure I follow but if your header.inc files are each named similar to the parent pages, e.g. whales.inc for /whales/, goldfish.inc for /goldfish/, then something like the following should work. Add the code to the template file of the child pages (i.e. the template file used by the children of 'whales', 'goldfish', etc.. include ($page->parent->name . ".inc"); Ideally, you also need to deal with what should happen if PHP does not find the specified include file. Welcome to the forums

Here you go....read this (whole) topic very carefully: Enable debug mode for only superusers or a given username $config->debugIf might also be of interest..

It's hard to debug without seeing the whole context. But the error message is clear, there's a problem somewhere with some selector. Problem is without debug on, you cannot really tell which line in what file is causing the error. What does your error.txt file say?

That syntax doesn't look right to me. If in a template file, you can call your module like this: $gCatcher = $modules->get("GoogleCidCatcher"); If in a function in a template file: $gCatcher = wire('modules')->get('GoogleCidCatcher'); If in a module you could use: $gCatcher = $this->modules->get('GoogleCidCatcher'); I can't find it now, but there is a way you can load a custom /site/config.php/ e.g. when logged as a superuser, load /site/dev.config.php. Any reason why you can't debug your module locally?

@DeM, Glad you got it sorted. As you noticed, what you wanted was not available right out the box.

The module only creates the role 'blog-author'. You have to assign the right permissions to that role yourself (when editing the role itself) and check and edit the respective blog templates' access controls (i.e. the 'what roles can access the pages using this template' setting in a template's access tab).

@quickjeff, Found a bit of time to work on this. The Authors' Dashboard was also relatively slow. Worked on that as well. Using a combination of $pages->count() (thanks @adrian) and raw SQL queries (as explained here) and testing using 10,011 posts, the main Dashboard loads in 0.3 seconds on my machine. I think that's an acceptable time (given the 10+ seconds it took me to load main Dashboard with 5K posts). Although I tested with a minimal comments count, I don't think this will make much difference where there's lots of comments (using SQL for the counts). I will also look at Categories and Tags (in cases where these could run into thousands) just to be sure. Posts Dashboard loads fast as usual. Unfortunately, I still don't have time to merge the new changes any time soon.

@all, Again, this is just a quick holding post....I am still tied up and cannot presently address your issues. @jonathan...thanks for taking the time to review the UI of the module. I hope to respond to your thoughts/suggestions soon. Thank you all for your patience...

Maybe how we do it in the Blog Module can be of help. Have a look at the Hooks here.

Should be fine but I suggest you thoroughly stress test...When I find some time I'll take it through its paces RE scalability.....

Updated my post above with how to do it

Yeah, will revisit this when I can find some time...For now, alternatively, you can skip the dashboard by making it redirect to posts....(so posts dashboard will be the landing page...) This at the top of the function blogDashboard should do it (i.e., insert as line #799): $this->session->redirect(wire('page')->url . "posts/");//redirect to posts dashboard

Oops, forgot one more (the archives table that's part of the main dashboard)...Please try to set a limit in line 931 as well and let us know if it makes a difference...

That's what I (must have) thought but not sure any more I must admit....haven't tested this in a while.... . Either way, lines 818-825 will need looking at closely again...

Ah, I missed that. Lines #818 and #821 also need limits (or some other filter)....(sloppy coding!!! Will optimise all three [eventually]....)....

Are referring to the tags of an image field? If so, this is a question for Ryan really since it is outside the Blog Module's control. If you are still experiencing this problem, please file your question in the general support forum or if you've confirmed it is a bug, in GitHub (PW-dev).

Apologies for the delay in getting back to you. The easiest way is to use the 'Cleanup Utility' to uninstall the Blog components (pages, fields, templates) and run the install wizard again (i.e. the second part of the install). Otherwise, you would have to fiddle with raw database values to change a whole lot of things. It can be done, but you need to know what you are doing. Thanks for using Blog.. Apologies for the delay in getting back to you. Blog utilises the (core) Comments Module that ships with PW. You'd have to direct this request to Ryan.

Hi all.... Apologies...I think I am now several months behind in respect of all my modules...I am still swamped with other stuff. My "I'll get to this next week.." have come and gone. I'am desisting from uttering such words for now... . I am hoping to get to things as soon as I can....This may take a while... @quickjeff. Thanks for using the module. About the main dashboard timing out, as you can see here (my bad) that has been on my to do list for a while. The other dashboards all have a limit (default = 10 if not set per user), hence don't time out (e.g. here....for Posts dashboard). For now, a quick solution for you would be to place a limit on that line...Of course that would mean it won't reflect a true count...but you could change the line as well to only display the latest posts. Eventually, I will address this more elegantly but unfortunately I don't have a firm time scale right now... @teppo, Thanks for reminding me about this..

@Adrian, Thanks for the suggestions. I am trying to create some time this week to look at these and other pending issues RE my other modules....I know I have been saying this a lot lately but other things/distractions beyond my control keep cropping up.....

@all....Please rest assured I haven't forgotten your requests/concerns. I am still totally swamped with other stuff. Hoping to free up some time soon to address all pending issue. Thanks for your patience.

@derelektrischemoench, Welcome to the forums. It works fine for me, both for 'included' (natural PW) children and native (MenuBuilder) children. Are you certain that your current class 'active' is not being applied as opposed to applied but overridden by another CSS class (e.g. 'last') via CSS Specificity/Cascade? Alternatively, can you confirm you are passing your $options properly to render() ? @all.... I haven't forgotten pending requests/issues...I'm just currently swamped with other stuff. I hope to address concerns soon. Thanks for your patience.

@Torsten, That's the current behaviour - only native menu builder child items & natural (tree) children associated via 'include_children' are affected by 'current_class_level'. I'll mull over extending the behaviour (via an API option) to include natural (tree) but non-associated children similar to the case you've described.

@hansv, Welcome to PW and the forums. Apologies I have been a bit busy and was not able to respond quicker. Glad you found the answer and thanks for finding the typo in the Readme I'll correct it. By the way, note that you can also pass a menu $page or an array of menu items in addition to the ID

@Metadope, I'll test this and get back to you. It may not be for a few days though... Btw, this line is only in the demo since the demo cannot know the type of 'blog style' selected by the user. Otherwise, you don't need it in your own template files since you know whether you installed blog with the comments feature.. $renderComments = $blogConfigs['commentsUse'] == 1 ? $blog->renderComments($page->blog_comments) : ''; So, just render blog comments if you need to without the conditional check