wes

Thanks, Adrian. I'll be sure to try that out. I'm assuming it'll work with 2.5 even though it's not listed in supported versions.

Having some issue with getting an iframe to save on a CKeditor text field (2.5.3). Things I've done to explicity allow it: - added "iframe[*]" to extraAllowedContent - added "IFrame" to the CKEditor toolbar - turned off CKEditor ACF - switched the field's "Content Type" from "Markup/HTML" to "Unknown" When pasting in my iframe code (it's a Vimeo embed code), CKEditor shows the iframe placeholder, but after saving the page, it's stripped out. For testing, I tried adding a simpler iframe using CKEditor's iframe toolbar button, but that also gets stripped out after saving. Anyone experiencing this, or have iframes working with their field?

Hi All, While troubleshooting some performance/load time issues when visiting an edit URL in the CMS, I found one page that had 60 hidden repeaters generated in the repeaters area. There was only one repeater visible with data, but I could have clicked "add new" 60 times and they would continue to appear (their html is in the source), all of which had blank fields. This caused the /page/edit URL to load in 7 seconds, and a couple of other pages with the same template are doing it as well (one has 97 items), some of which never finish loading. This particular repeater field's "Ready-to-edit new repeater items" is set to 3. Has anyone ever experienced an issue like this? Possibly useful info: I'm using the Page Edit Field Permission module to control editing permissions for this repeater field.

Yes good point. It's better in this situation to just put together a quick front-end login template. Thanks Soma

I'm trying to enable temporary site-wide password-only access, and I have this small snippet in my header include: if(!$user->isLoggedIn()){ $session->redirect('/cms/login/',false); } Works fine for forcing logins on all pages across the site, but my end goal is to actually redirect them back to the page they came from. Currently they just end up in /cms/. Is there a GET var I can pass /cms/login/ which will specify where to send them next? Something like this I was thinking: $session->redirect("/cms/login/?next_url=" . $page->path, false) Worse case I could put together a custom login template, but was curious if there was a simple solution.

I personally don't see a reason to extend pwire's core to support Craft's matrix block stuff. It's taking the repeater paradigm a little too far / specific for inclusion out of the box. For me, processwire's repeater fieldtype is pretty much perfect as-is, and actually is the sole reason I started using processwire. The way I see it, the jump from child pages to in-template repeaters for organizing certain kinda of data is substantial and incredibly useful from a client UX/UI perspective, but the jump from the existing repeater type to something like matrix blocks from Craft is not as substantial. Just use multiple child templates I'm curious Ryan, what for you is the ideal situation for repeaters vs child pages? For me, I use them in situations where it's helpful to see repeating data all at once, as opposed to seeing a list of child pages and having to drill down into the individual pages to see specific data. For instance, if I have a relatively complicated gallery in a page (which requires more fields than the images field offers) repeaters are perfect because they allow clients to see all of their images in a single page, drag them around, etc. If I were to build all the gallery fields into a separate template and have them as child pages, it would be difficult to visualize the entire gallery all at once. So a repeater works wonders. Ryan I hope you aren't considering phasing out repeaters because you don't use them yourself. For me, it's a killer feature. They aren't candy, they serve a real distinguished purpose from normal child pages. When the next version of pwire comes out with gridded image galleries, that will be icing on the cake for my CMS wishlist. The only weakness I see with the current pwire release is the inefficiency of viewing image galleries. Pwire is near-perfect

Awesome, thank you! Can't believe i missed that module in my initial searching. (link here for anyone finding this thread in the future)

I looked through field settings, but it doesn't seem to be possible to make a field hidden/disabled on a permissions or superuser basis. For example, if there were fields in a template type that are too complex or "dangerous" to allow editing by a normal user, but should appear for an admin user to edit. Right now, if I set a field to be hidden, it hides it from all users, even the superuser. Anyone ever have the need to get around this? Worse comes to worse, I'll code a simple admin-only page with autogenerated form fields that will allow the admin to edit the specific fields while they stay disabled within the normal pwire UI. Thanks for any suggestions!

I've just tried changing FieldtypePage module as per Ryan's post (and then changed my custom field selector to template=work,include=all), but I still can't save the unpublished pages I selected from the Page field-- they appear, but after saving my selection, the user page reloads and there are no selected pages within the field. It seems the issue is not with displaying/querying unpublished pages to display within the Page field (that worked before with status=unpublished). Something happens between selecting the pages within the field, submitting the form, and ProcessWire deciding whether or not the unpublished pages submitted for the field are valid as input or not. Am I just completely missing what people are talking about in this thread? I feel a little confused about the conversation, heh...

Are you both still referring to the dev version? I tried it with 2.3.0 (template restriction on Page field, SelectMultiple UI type), and I can't see/select the unpublished pages.

I appreciate that you're looking into this, kongondo. Looks like I may have to figure out another way of achieving this if this issue is still being worked on in the dev branch. Will keep my fingers crossed though

Hi All! Quick preface just to explain my reasoning behind what I'm trying to make: I have a web portfolio with a bunch of projects. Some I want to keep as unpublished for archival purposes, not viewable by the public. But sometimes I will want to email a potential client with a guest user/pass and have them gain access to these unpublished pages (that I specifically curate per-user) through the normal project listing template. I didn't want to use hidden pages in case they tried to share the URL with someone else. Stage 1 of my idea to accomplish this is add a new field to the system user template (called special_pages). I set the field type to page and set a custom selector on it that works great in terms of displaying pages for selection (status=unpublished, template=work). However, when I select a few pages using any multi page select UI and click "save" it doesn't actually save my selection when I reload the user page. If I change the selector I can successfully save normal pages. Any ideas? If it helps reach a solution, stage 2 of my idea was to write a module that hooked Page::viewable and checked if the logged-in user had the page selected in this field on their user page. Haven't really messed around with that yet since I'm stuck on this first part.

That's good to know. Forgot about the fact that image fields can have multiple items, so by default it would make sense to be an array. Thanks!

Ah, fixed it. You were right, it was something about output formatting. Doing a $item->setOutputFormatting(true) right before the echo statements did the trick. Thanks, Soma.

Hmm, doesn't print anything. I would think that 'first' wouldn't be accessible because $item->my_image should be a PW file object ($item being an item from the repeater field).