ryan

Thanks for your message and PR. This was fixed yesterday morning as soon as I saw it. I can only guess that I was still getting an older cached version of the JS file when testing this change.

Lets say you've got the page /family/ that has everything below it you want protected by a login. Create a new role (in Access > Roles), call it whatever you'd like but maybe "family" is a good name. For permissions, check the box for Page View, and that's it. Create one or more new users for your family, and give them the family role. In your admin edit the template used by your /family/ page (let's say it's also called 'family') and go to the 'Access' tab. Check the box to enable access control. For view access, check the box for "family" but not for "guest". Also when editing your family template, for the section on "what to do when a user doesn't have access", choose the box to redirect them to the login form. Or if you want your own custom login form, you can later change this to redirect to a custom URL that contains your login form. In your /site/config.php file, see the section on the "pagefileSecure" option and determine if that is something you will want to use or not. By default is is off.

This is significantly more scalable and resource friendly than repeaters. It's directly connected to a single DB table without any other overhead.

That usually means that 1) your roles don't permit you publish access; or 2) not all required fields are filled in.

Actually either syntax should work here. The $users->add('name'); function is a valid way to create a new user. Though the $u->of(); and $u->save(); immediately after your add() aren't necessary. The $users->add() syntax is newer though, so may not be present in past versions of PW.

Perhaps FieldtypeFloat could temporarily switch the locale back to C whenever it needs to operate on it, then switch it back.

Are you using CollagePlus on it's own or the CollagePlus module in ProcessWire?

It sounds like you are talking about from the API side. You can work with repeaters just like any other pages, but you just have to know where to find them. Your repeater items are going to be using a template with the name of your repeater field pepended by "repeater_". So if you've got a repeater field called "slideshow", then pages within that repeater are going to be using the "repeater_slideshow" template. As a result, you can query them like this: $pages->find("template=repeater_slideshow, ..."); Repeaters are kept in the admin structure, so if your code needs to do it's thing on the front-end of your site, then you'll also want an "include=all". Note that unpublished+hidden repeaters are considered unpopulated "ready" pages, so you can safely skip over them.

Actually, you can do this on the dev branch. Lets assume that cities are children of countries and that is reflected in your page structure (i.e. /countries/france/paris/). Create your 2 page fields (country and city), and configure 'country' as a single page field with "parent" set to "/countries/". Next, for the "city" field configuration, use the "Custom selector to find selectable pages", present on the "input" tab. In that field, enter "parent=page.country". Save and try it out. This works with select, selectMultiple and asmSelect fields (and possibly others), though not yet with checkboxes, radios or PageListSelect.

Hard to say for sure. But those 4 unpublished records were most likely intentional 'ready' pages. This quantity is defined in your repeater field settings (details tab).

I have no experience with Amazon's setup here, but definitely curious. Have you tried enabling PW's debug mode in /site/config.php just to see if maybe some errors are occurring that might be getting missed? It'd also be interesting to know if any errors show up in your JS console. I'd also be curious what versions of MySQL and PHP are in use here. If you PW login and a phpinfo(); link you can PM me I'll be happy to take a look.

require_once isn't ideal for prepend/append template file settings. When you call $page->render(); you want to know that everything you expect to be included is included. A lot of us call render() methods on other pages, which a require_once() could break. If there are things that need to be require_once (like function or class definitions) you can always move those to another file and require_once them from your prependTemplateFile. My prependTemplateFile usually looks something like this: // initialize page regions with default values // this will be output eventually in _main.php $headline = $page->title; $browserTitle = $page->title; $body = $page->body; $sidebar = ''; // include shared function libraries require_once('./includes/finder.php'); require_once('./includes/render.php'); As for your particular case, it sounds like you've got some logic running after output has started. You want to move that logic to somewhere before output starts. Given that, prependTemplateFile is not an ideal place to output header markup. However, if you want to continue doing that, then you may be able to place this at the top of your prepend TemplateFile: if($page->name == 'http404') return;

The unzipping in that part of ProcessWire doesn't use ZipArchive, and it needs to be updated. ZipArchive didn't used to be very common, so calling an unzip utility from the shell (what PW does) used to be more reliable across servers. Unfortunately that method doesn't work on Windows servers. Also, ZipArchive is very common now and this part of PW just needs to be updated to use it instead of the older method.

Also, you ideally want to sort these before they come out of the database rather than after. That happens in your $pages->find() or $page->children() or whatever code comes before the code you posted that populates $results. i.e. $results = $pages->find("template=blog, sort=-blog_date, limit=3");

You should be able to do categories with form builder in this case. But note that your 'category' field will have to be a field of type 'Page' both in your form and in your ProcessWire fields. I'm guessing that you've currently got 'category' as a regular select field (rather than Page field) in Form Builder?

I didn't realize this aspect of the file fields output. I've put this on my to-do list for the next version of the module (actually for ProcessPageSearch, which is what this module uses).

The only more complicated stuff stored in the session would be CSRF protection. But I don't think that was the problem here, otherwise you'd get an error message telling you about forged requests. What browser were you using before where it wasn't working?

Usually when I need to truncate something it's because it needs to be a summary that fits appropriately in a defined area and consistently with other items of the same type. As a result, having HTML in the truncated text is no good, so I'll include a strip_tags() as part of the truncation process, then wrap it in my own <p> or what not. Most of my sites have a shared truncateText() function somewhere in there that works kind of like this. Maybe there should be one in PW's core, not sure. function truncateText($text, $maxlength = 200) { // truncate to max length $text = substr(strip_tags($text), 0, $maxlength); // check if we've truncated to a spot that needs further truncation if(strlen(rtrim($text, ' .!?,;')) == $maxlength) { // truncate to last word $text = substr($text, 0, strrpos($text, ' ')); } return trim($text); } $summary = truncateText($page->body); echo " <a href='$page->url'>$page->title</a> <p class='summary'>$summary</p> ";

Just tested here and Chrome and it seems to be working for me. I'm on dev 2.3.7, though I don't think it would matter to comments manager. Are there any other factors you can think of or steps to reproduce?

Here you go: Events Fieldtype/Inputfield

This module serves as an example of creating an editable table of data as a Fieldtype and Inputfield in ProcessWire. In this case, we create a simple table of events each with date, location and notes. This pattern can be adapted to nearly any table of information. Note that this module is intended as a proof-of-concept. If you find it useful for the example scenario (events) then great, but keep in mind it is not intended as a comprehensive events solution, where using ProcessWire pages may be a better fit. This is a pattern I've used for creating tables of data in ProcessWire for many different Fieldtypes/Inputfields and thought it would be good to setup a proof-of-concept example like this to share. Module Page / GitHub Page Install Copy the files for this module to /site/modules/FieldtypeEvents/ In admin: Modules > Check for new modules. Install Fieldtype > Events. Create a new field of type Events, and name it whatever you would like. In our examples we named it simply "events". Add the field to a template and edit a page using that template. Output A typical output case for this module would work like this: foreach($page->events as $event) { echo " <p> Date: $event->date<br /> Location: $event->location<br /> Notes: $event->notes </p> "; } This module provides a default rendering capability as well, so that you can also do this (below) and get about the same result as above: echo $page->events; ...or this: foreach($page->events as $event) { echo $event; } Finding events This fieldtype includes an indexed date field so that you can locate events by date or within a date range. // find all pages that have expired events $results = $pages->find("events.date<" . time()); // find all pages with events in January, 2014 $results = $pages->find("events.date>=2014-01-01, events.date<2014-02-01");

This has been added in the latest commit. I also updated CKEditor to 4.3.0.

The $map->render() requires either a Page with a 'MapMarker' field or a PageArray with multiple pages, each containing a 'MapMarker' field. If you are giving it a PageArray of multiple pages, and it's only showing a marker for 1 of them, then chances are that only one of the pages you gave it has a 'MapMarker' field. Keep in mind the field must be named consistently with what you tell it. Meaning, if you are calling $map->render($features, 'MapMarker', $options); then every one of the pages in $features must literally have a map marker field named 'MapMarker'. If they don't, then chances are that $features is not the group of pages you really want to send to render(). But $placepage clearly isn't either, since that's just 1 page (which is only going to print 1 marker). Based on looking at your code, I'm guessing this might be what you want? $features = $pages->find("parent=/events/, bfd_day.name=$todayday, bfd_month.name=$todaymonth, sort=bfd_year"); $markers = new PageArray(); foreach($features as $feature) { $markers->add($feature->bfd_events_places_id_list); } $map = $modules->get('MarkupGoogleMap'); $options = array('width' => '100%', 'height' => '400px'); echo $map->render($markers, 'MapMarker', $options);

I've not had experience with the DataTable module, so replying more to bump the topic up to someone that has. But everything you've mentioned sounds feasible to me (outside of any specific module), but would no doubt involve significant development.

The term "repeater" in our context means repeating the same type. What's being described above is essentially ProcessWire's pages system, and repeaters aren't meant to replace creation of page structures or groups of different pages. If there were a repeater type field that did that, there would have to be a different name for it.