ryan

I actually ran into this issue myself on Wednesday when I was upgrading a client's PW install running PW 5.2.17. I corrected the issue and committed it yesterday morning when I got an email about this thread. I hadn't been through the issues list this week yet, but looks like Roope submitted the exact same fix more than a week ago. I have no idea why PHP 5.2 doesn't like the syntax, or why I changed the syntax in the first place, but the latest dev should be fixed to work with PHP 5.2.

Dragan is right, it your relative URLs wouldn't work just because the path may be changing relative to the language. The fix is as simple as using an absolute path rather than a relative one.

It sounds like you want to change the field attributes just for the context of a single template, is this correct? If so, look into $fields->saveFieldgroupContext().

Matthew, I'm assuming this this error occurs after you perform $pages->find(), $pages->get(), or $page->children(), type call somewhere that contains a selector that looks like "title=some title, with a comma in it"? Wanze is right that you would want to use selectorValue on the "some title, with a comma in it" before bundling it into the selector. But if you are just creating pages, rather than querying pages for a title, then let me know.

All image and file fields technically support multiple files. In your field settings, when you set it to contain a max of 1 file, you are really telling it to behave as a single file on the front-end of your site (for API convenience). But when it comes to administering files/images from the API side, all image/file fields are treated the same (when output formatting is off, as it would be when performing any kind of page manipulation). What I might suggest is to use this bit of a code instead when replacing your single image: $thisPage->image->deleteAll(); $thisPage->save(); // now add your new image

If you treat each photo as a page, then you'll have no problem with checkbox-style tagging (categorization), using a Page reference field. One way to do this is with an image field and a Page reference field in a repeater. This would be a fine way to go, but you'd be limited to uploading 1 photo at a time. Whereas with a regular images field, you can drag in a bunch at a time. Lets say you didn't like the repeater option due to the 1-file at a time issue. The way you describe it, you want to have an individual page (like an event) with a photos field, and the ability to tag those photos with predefined tags. I think of tags as being something more free form, and predefined tags as really being more like categories. This is not something that the Image fieldtype does on it's own. It does support tags, but it doesn't connect to an external database of them so that they can be predefined like categories. You could solve this by making your own Inputfield module that extends or modifies the existing InputfieldImage module. But for the simplest solution, I would probably just use the tags as they are already provided by the module (free form). You can use the API to find pages with images containing specific tags. To summarize, the most likely options are to 1) use a repeater with an image field and a page reference field, and compromise on the 1-file-at-a-time thing. 2) use the existing Image field tags option, and take the free-form compromise. 3) extend or modify the existing Image inputfield to work the way you want it, with the compromise being having to get deeper into the PHP side.

Thanks, that looks better–I will give this one a try.

Yes, that's better. Beyond creating the directory for you if it doesn't already exist, it's also good to note that the directory might not literally be the $page->id. If you've got the $config->pagefileSecure=true; option in your /site/config.php, then unpublished and non-guest-accessible pages will have file directories that start with a period, in order to prevent web access, i.e. ".123" rather than "123". Using the $page->filesManager->path or $page->[your file field]->path, rather than constructing it yourself, ensures that all of this continues to work as it should.

Thanks, I have added this to the /wire/templates-admin/styles/inputfields.css .Inputfields > .Inputfield > .ui-widget-content { /* the Inputfield's content, padded from the borders */ padding: 1em; overflow: auto; } ...but am seeing odd results, specifically this scrollbar: So I changed it to this: .Inputfields > .Inputfield > .ui-widget-content { /* the Inputfield's content, padded from the borders */ padding: 1em; overflow-y: auto; overflow-x: hidden; } ...and that seems to work. I'm not seeing any more oddities, but will keep testing. Just wanted to make sure this is consistent with what you guys are suggesting? Also, it was mentioned earlier that there were various CSS hacks already in place to solve the problem that this CSS fixes? I guess I'm not sure what or where those are, but if you can point them out, it might help me to better understand the issue. Not to mention, if there is redundant/unnecessary code somewhere, I'd like to remove it.

Very impressive module Horst! I look forward to using it. Please post to the modules directory too if possible. Thanks for your great work here.

I think it's best though just to keep it simple and use the template file home.php as your homepage template, and keep that on your root page.

They shouldn't be compressed. Regarding the 1-line issue, we can correct this on PHP 5.4 and newer as json_encode() now has a JSON_PRETTY_PRINT option, which makes it output the JSON in a human readable way (and I'm assuming a much easier-to-version way). I'm going to add a check for PHP 5.4 so that we can start taking advantage of this now.

The $cacheFile->remove() should remove all files in the cache directory for that page. Probably what would be better is just to call $cacheFile->remove() regardless of whether the individual cache file exists -- so your suggestion is a good one (but will use remove rather than removeAll). Secondary ID is a combination of $options (prependFile, appendFile, filename), page number, language and perhaps some other things I'm not thinking of. I can look at opening it up to more options. MarkupCache is also another option, that lets you have full control over the cache ID. I'll look into this option. Though the MD5 includes things outside the $options array as well, but perhaps the entire $options should be part of it.

I actually have no idea what you guys are talking about–tell me what to change? I understand code better than concept when it comes to CSS, so might need you to be literal as to what you suggest?

When you uncache a page, it also triggers an uncache() method on all the page's fields. Fieldtypes can decide how to handle that. If those fields are objects, then they may choose to uncache themselves as well. Depending on the fieldtype, this could mean that they essentially reload from DB the next time you access them. Text fields on the other hand are just text, not references to other object instances–so there aren't any external references to uncache. When you clone a page, it creates a second copy of everything (including the fields it references). By uncaching the clone instead of the original, you are effectively uncaching it from the ID cache of $pages only. A shallow uncache rather than a deep one. All the fields on your clone are still being uncached, but your original $page is still in tact and an uncache hasn't uncached your changes. Basically, I think what you are doing makes sense and is probably the right way to go here. Though it might make sense for me to add a $shalllow option to the $pages->uncache method, so that you could bypass a deep uncache if needed.

Would something like this work? (written in browser, so might need tweaking). This should print all events sorted by date descending, but grouped by day and sorted by time ascending within the day. $allEvents = $pages->find("parent=/events/, sort=-date"); while($allEvents->count()) { $event = $allEvents->first(); $from = strtotime(date('Y-m-d 00:00', $event->getUnformatted('date'))); $to = strtotime("+1 day", $from); $events = $events->find("date>=$from, date<$to, sort=date"); echo "<h3>Events on " . date('F j, Y', $from) . "</h3>"; foreach($events as $event) { echo "<p><a href='$event->url'>$event->title</a> $event->date</p>"; $allEvents->remove($event); } }

This is a planned future addition, not yet implemented.

For pages that are only containers, I usually try to implement them as just a general listing page of the children so that there is something there if someone goes there. Basically, I like containers that behave as containers, listing what children they have. I also check the "hidden" box for the page, so that it stays out of navigation and searches, when desirable. Other strategies I've used are to: Not implement a template file, so the page throws a 404 when you access it; Have it redirect to either the first child, or it's immediate parent, or the homepage, using a $session->redirect().

When saving files to a page's path, Wanze's got the right trick there, but do it like this instead (which ensures the directory is created if it's not there already): $document->save($page->filesManager->path . 'myName.docx'); You might also want to add it to an existing files field on your page? $page->files->add($page->filesManager->path . 'myName.docx'); The above assumes your files field is named 'files'. For temporary, non-web accessible files, I usually save to /site/assets/cache/ $document->save($config->paths->cache . 'myName.docx'); If you need to store multiple files, it's best to have your module create it's own directory under /site/assets/cache/.

That's right. So if "{$page->adresse_detail}<br />\n" is literally the only thing being output by the template file, then that trailing "\n" will be stripped. But in the context of a larger HTML document, you wouldn't see the "\n" stripped.

This is why I always configure the settings on the "family" tab of each template before delivery, at least for sites that will ultimately be managed by a client. Presumably these same settings would be applicable for a Fieldtype/Inputfield module that pursues this multi-template repeater strategy. This was always one of my concerns with repeaters in the first place. It might be a bigger concern with a multi-template repeater. I don't see 1-screen page editors as something that should be scalable like this, at least not too far in quantity. Whereas the page tree is, and should be. Though at some point I would like to introduce pagination into repeaters for the admin UI, but a little worried that might encourage more bad repeater behavior. I do like repeaters, but it does seem like they get used for more things than they should, at least based on questions that have sometimes popped up in the forums. They introduce ambiguity into how to solve a particular problem. Before repeaters, it was always easy to answer how to solve any problem: use pages. After repeaters, the answers aren't as easy. Though for the places that repeaters are the right answer, they are a nice time saver. But I rarely find a use for them in my own projects. Shifting gears back to append ideas to my previous message, and maybe thinking of something different: one idea could be to have a checkbox on each template that says "Children tab shows: 1) links to child pages; 2) editors to child pages". If they select "2" then the children tab would show those iframe editors to each child page in a repeater-like format, and an add button, like mentioned in my previous post. It would show that rather than a PageList. An option for pagination would be a must have though.

ProcessWire only uses this method if you've enabled the $config->pagefileSecure option in your /site/config.php, and then only for files on access controlled or unpublished pages. I'm not a fan of this method of file delivery unless the file needs to be behind a wall for access control. Files are static assets that Apache can deliver without any PHP/MySQL overhead necessary. Delivering files through PHP consumes a lot of unnecessary resources. But if the file needs to be access controlled, then of course it's the way to go. But given that files really shouldn't be delivered by PHP unless necessary for security, these are the issues: Basically, I don't think direct file replacement is worth the compromise. Abstracting the file name to a tag (like mentioned in my prev message) is a clean compromise. Single file fields already support replacement (just drag and drop a new version on top of the old), but don't currently retain the filename unless you drop the same filename on top of it. So what I also think may be okay is letting the admin optionally specify a target filename for single-file fields with the file field settings. This would still be a cache concern, but would at least prevent recycling of old filenames.

…Until you do it from the API, Batcher or ImportPagesCSV.

PageLinkAbstractor isn't obsolete because its doing a little more than this solution is. PageLinkAbstractor is abstracting the links to page IDs, meaning it has the benefit of being able to keep links consistent with pages that move. I also don't see any potential conflict between the two, but if you are using PageLinkAbstractor, then there's no reason to enable the Markup/HTML option in your Textareas.

Any reason FancyAdmin isn't in the modules directory? Just re-watched the video, very nice.