kongondo

Do you mean to allow empty values in both CSV imports and manual entered values? Both should be quite easy to implement. I think I'll implement them as separate options though. Overwrite vs Append: Off the top of my head I think it overwrites. I'll have to confirm this one. Export to CSV: Good idea. Added to my @todo

Seen this? Site-wide File Manager Support forum: https://processwire.com/talk/topic/630-module-manage-files/ Related: https://processwire.com/talk/topic/11040-visual-page-selector-commercial-page-picker-module-for-processwire/

@mauricius. This is a very beautiful implementation Welcome to PW and the forums...

Should the {title} be name? Since it is used to form the URL? Just curios whether the module will convert it to name (haven't used it before)

You have two options for the dropdown: Page Field or Select Options Fieldtype

That's a better description...Like @tpr has suggested, this would be better managed on the admin side rather than in an include file for at least two reasons: 1. Your images will have a description - no need to type that text in some template file where your client/editors will not be able to change it 2. Dynamism...in case needed in the future. Here are some options: Option 1: Create an image field (e.g. call it content_header). Attach this image to the template used by your parent pages (Whale, Guppie, etc). I am assuming all these parent pages have a single shared template (please note, I am talking about a template here; not a template file). Image fields have a description text area. Use that for your 'brief descriptions'. content_header->description will give you access to those descriptions. More here on image fields. Then on the children pages' template file(s) call on their parents' image field and description...e.g. $page->parent->content_header->description Option 2: Create a dedicated page to hold all the content headers and their descriptions. Let's call it 'Content Headers'. Add one image field to it that accepts multiple images. Add your '25' images named similar to your parent pages, e.g. whale.jpg, guppie.jpg, etc (if practical, or use some other naming format). I can't remember if you can use the API to find an image using its name (i.e. $image->basename). Anyway, you can activate the 'tag' text area of an image field (in the field's settings). In that case, no need to give your images any specific name. Then, give each image a tag that is identical to your parent pages names or titles. You can find each specific image using their tag, i.e., $page->images->getTag('mytag'); Or, in your case you refer to the dedicated page, e.g. $p = $pages->get('name=content-headers'); $chImage = $p->content_header->getTag("$page->parent->name"); If you gave the whale header image a tag called 'whale', then, when viewing Whale's child pages, this image will be retrieved. The advantage here is that you can edit all your content headers in one place. Option 3: If your descriptions are quite long, then, create a dedicated text field(s) and a separate image field using either of the above options Option 4: I think you could also use repeaters or PageTable(?) Haven't tested the above code and I have been away a while, so, there could be other better ways to accomplish what you are after.

Although it works, seems a bit strange that you are exploding the page's URL string to get (I suppose) the name of the parent page. ProcessWire already has methods and properties to get you all the information you need about a page (similar to my example above). What might be a 'better' way depends really on the answer to the questions: What is the content of headerImage.inc (is it just an image?) Is that content dynamic in itself (i.e. will you be editing headerImage.inc) or static? Otherwise, like I said, there could be a dozen (better ) ways to achieve the desired effect. You could still get away with one or two templates. Depending on the content of headerImage.inc you could have for example a single page with all the header.incs as fields, a single image field that holds multiple images, several pages, etc. Hard to answer without answers to my questions above ...

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.