horst

I would consider this an issue. If I get you right, it only doesn't work with the new approach? I assume, it has to do with the automaticly parsed / rendered method of PW, that reads your code (as default setting) and then overrides it with the current modules settings. No chance to override a setting for us. Butthis is a valid use case. I think we should make an issue on github and see, if Ryan can add this more fine grained control back for us.

Some good news! I have experimented with the background for transparent images. I have tried lots of checkerboard images, with two or three colors, with alpha transparency or not. Finally I came to the conclusion that it is much better to use some photoshop noise. Here is my testimage. A png with black, white and midgrey text / symbols plus a grayscale full opaque and half transparent: And here is a screenshot how it looks as thumbnail in the images field with some noise background: This way we would not need any steroids, no config settings, nothing else.

Have you checked the access settings for the field too?

My code example is a bit lengthy. I copied it from an event template with another usecase. There we have a start_date and optionaly an end_date too. Only all future events and or currently active events should be shown on the site, also those where the start_date is in the past, but the end_date is in the future: $threshold = strtotime(date('d.m.Y 00:00:00')); $selector1 = "template=ptlist-events, event_disabled=0, event_date_start>={$threshold}, sort=event_date_start"; $selector2 = "template=ptlist-events, event_disabled=0, event_date_end>={$threshold}"; $events = $pages->find($selector1); // find all events that start today or in the future $events->add($pages->find($selector2)); // find all events that end in the future, even if they started in the past, // and add to PageArray $events->sort('event_date_start'); foreach($events as $k => $v) { printEvent($v); } PageArray stores by ID, so there are no duplicate entries in the final PageArray.

I call boxes of filter links here via ajax on demand: http://joerg-hempel.com/archiv/ In the ProCached file, the content is empty. On demand it fetches it via ajax request, and on PW side via a page and urlsegments. You can use the network tab to view the request. But it is only requested one time per session. I store the fetched content in client browser local session storage, to avoid multiple server requests for the same content, if the user clicks around on the filter tabs.

<?php $threshold = strtotime(date('d.m.Y 00:00:00')); // = today $selectorFuture = "parent=/shows/, show_date>={$threshold}, sort=show_date"; // or: sort=-show_date $selectorPast = "parent=/shows/, show_date<{$threshold}, sort=show_date"; // or: sort=-show_date foreach($pages->find($selectorFuture) as $show) { // echo table rows here ... } foreach($pages->find($selectorPast) as $show) { // echo table rows here ... }

+1 for hiding the button by default (re-move the bookmark-thing from it) @Kai: I'm with you. The (unconfigured) button at such a prominent position is not useful. It produces confusion. But to clarify: the default behave of creating a new page in PW is to select / click on the parent page and select [new] from the popup link list. As LK has said, PW needs to know what page should be the parent for the new page. And now, imagine a site with lots (multiple thousand!) pages and lots of templates and a deep hirarchical tree structure. Do you have it? It would be very uncomfortable to first have to navigate deeply into the hirarchy and have to use the pagination too, before one coud select the parent page for creating a new one. This is the situation for what the ADD-NEW button was created for. Devs can setup template family relations and decide to display an AddNew link for a specific page type there. Now, when an autor / editor need to create a new page of that specific type, which parent is deep into the tree hirarchy, they only need to select it from the big ADD-NEW button and PW does the rest. It is a very fine, time saving, useful and comfortable feature. (when it not is showing up unconfigured ) We will add it to the issue list.

Sorry, but I cannot resist: For me this sounds funny, as the index.php is wrapped around everything what has to do with / runs within PW, including 1k+ core files, all your site files, incl. templates, third-party modules and optionally other included scripts. Measuring the index.php execution time seems to be not the most useful concept for anything more than determining the total execution time. Also, if you have encountered times from 0.5 to 3-4 seconds for the same requests, it looks to me more to be server side issues than not performant coded templates or third party modules. If you would have encountered a request with a specific template to be always 3-4 seconds whereas others run under 0.5, this would be an indice for code bottle neck or that like.

Congrats!

Just to be safe: which version of PW? I assume PW 3+ or 2.8+ But regardless of that, you need to install this: http://modules.processwire.com/modules/image-animated-gif/ EDIT: For the record: We want to implement an equivalent of the above module into the PW 3+ / 2.8+ core. But I first need to modify / write it.

Every thing is a page! Om! Every page has a ID! Om! $articleCountPerAuthor[$author->id] = $articleCount; Should be save!

This should be read by @Pete. Maybe, this behave has to do with change of thread types? (formerly Question / Answer)

Sorry, I forgot about it. Another solution would be to stick with PW 2.7 and the (old) SessionHandler-DB, but uploading multiple images packed into a ZIP! (only one ZIP at a time) This I uses on a client side with (old) SessionDB-Handler since PW 2.5, (upgraded to 2.6, then to 2.7) for years now, and it works correct!

If you can, disable the session DB-handler. It is known for this behave in regard with multiple parallel images uploads. Or, if you cannot switch to session handling via files, the only other alternative is to switch PW Version up to PW 3.0.21+ (?) not sure the correct version where DB-Sessionhandler was updated / corrected. Other possiblities are not there in your case, I believe.

Witch PW version is this on? Do you use DB-SessionHandler? Can you view Apache logs? Any entries there?

@flydev: only one suggestion: it should be $child->numChildren(true) instead of $child->numChildren // what is the shortcut to $child->numChildren(false) Read here why: https://processwire.com/talk/topic/13950-show-image-childrens-children/#comment-125410

Hi, I haven't followed to the end here, but saw something above what I want to mention: using <?php if($page->numChildren) { counts hidden / unpublished / protected pages too, per default. This is implemented in $page to give a quick "overview" of totals, but unrelated to their states. This is useful and was implemented for cases where you have lots (thousands!) of children, to give an raw overview. But in your case, with only a few or NO children, you want to query the exact visible / accessible children for guests. You need to use <?php if($page->numChildren(true)) { see: http://cheatsheet.processwire.com/page/built-in-methods-reference/page-numchildren-bool/ TLDR Before Ryan introduced numChildren(false|true), only $page->children()->count() was available, what needed to read / open all childpages and results into much memory and cpu usage and execution time. With numChildren(false|true) we have a much faster alternative. I think the fasted case is with the param set to false, the default. (Thats why it is the default . But this is only my guessing.)

what modules / third party modules are runnin in this installation?

I have skim-read it. Best sentence I found somewhere in the middle: Keeping things simple for now Very good resolution.

@LostKobrakai: Nice and much better solution! This way, one can use it for all WireMail modules out there!

To be correct: Install pim, what installs pim1, go to modules / site, install pim2 and use pim2load(). It needs a rewrite someday for recent PW versions (2.8+ & 3.0+)

Hi, no, it isn't possible currently out of the box. You can hook into the ___send() method, and add / change the line 705, where the message normally will be send. Don't know if this is an easy task, as the method is really huge. I find this useful too, and add it to the feature request list of the module, but don't expect an early release.

Hi. There are no plans to update Pim2. And if it will be updated, the version number from Pim1 will be bumped up, so that it shows up in the update modules list. (Pim2 is handled as submodule of Pim, Pim1)

I don't know homebrew, but to me it looks like the ini setting for "always_populate_raw_post_data" isn't (finally) set to -1. Have you checked it on runtime? The issue simply is, that you get a PHP warning as return of an ajax request, what then breaks your app (PW), as it expects another return, (a json object, and not a PHP server warning). You need to disable all php warning output, other then logfile, you need to check your ini settings for the mentioned setting on runtime, and / or you should set the mentioned setting on runtime too. Sometimes there are multiple php.ini files on a system, and it isn't quite obvious which one(s) are involved. So, additionally you may scan your filesystem for all php.ini files and explicitly set "always_populate_raw_post_data" to -1 in every file, if the runtime check shows that it isn't set to this.

If I understand you right, you simply need to create all fields you need. (In PW, all fields are custom fields!) Put your desired fields together in a template, and use this template when importing external data into pages. imported-data: - import 1: extid = 1, text = bla, amount = 10, ... - import 2: extid = 7, text = blu, amount = 7, ... - import 3: extid = 21, text = blo, amount = 0, ... Does this help?