Jump to content

wes

Members
  • Posts

    26
  • Joined

  • Last visited

Everything posted by wes

  1. 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.
  2. 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?
  3. 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.
  4. Yes good point. It's better in this situation to just put together a quick front-end login template. Thanks Soma
  5. 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.
  6. 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
  7. Awesome, thank you! Can't believe i missed that module in my initial searching. (link here for anyone finding this thread in the future)
  8. 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!
  9. 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...
  10. 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.
  11. 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
  12. 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.
  13. 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!
  14. 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.
  15. 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).
  16. Hi All, I'm trying to access some files in a PW site by using a command line script. For some reason certain file properties (as defined in the cheatsheet) aren't available on images inside of a repeater field, or perform unexpectedly. Example below: include("./root/index.php"); foreach($wire->pages->get("/my/page/path/")->the_repeater as $item){ echo $item->my_image; // prints only the file name, no path (expected) echo $item->my_image->url; // prints directory the file is in; e.g. '/site/assets/files/3205/' (unexpected, b/c this would normally give full URL to file when using through my templates) echo $item->my_image->filename; // what I really want to use, but prints nothing, just a blank line echo $item->my_image->ext; // prints nothing, just a blank line echo $item->my_image->width; // prints nothing, just a blank line } Any ideas? Thanks!
  17. Thanks for confirming this, Soma. I'm going to write a github issue right now.
  18. Good point. I'll submit an issue to github. I guess I imagined github issues being only for absolutely positively confirmed bugs, and I wanted to see if someone on the forums have used images in repeater fields as a non-admin user with positive experience.
  19. Running into some problems when uploading images when logged in as a non-admin user. I have a repeatable field set up with an image upload and a few other input types. I can edit and save the other input types fine, and edit all of the other non-repeatable fields on the page (including images), but when I upload an image within the repeater, I get the following error: I can save the page successfully when editing other fields within the repeater, but not the image field itself. It fails with the above error after uploading. I doubt it is related to roles because I can edit other fields without an issue. It works as admin, however. Things I've tried: -edit + save other fields within the repeater, and then try to upload an image -updating my wire directory to the latest from github -creating a new user, with a new role, and adding this role to the page template (same issues) Any ideas? Thanks!
  20. Ohhh, good catch. Switching the quotes in fact did the trick. Your get/find method works, as well as my original method. Thanks everyone.
  21. Hello, So, I have course pages and faculty pages. When I create a new course, I can associate it with 1 or more faculty members by adding them to the course_instructors Page field. When I visit the faculty member's page, I want to view the courses they teach. I'm trying to do this with a selector: // on the faculty member's page $spring_courses = $pages->find('parent=/courses/spring/, course_instructors=$page'); $spring_courses is empty. Just to reiterate, course_instructors is a page field that can have multiple pages in it (multiple instructors). I'm basing my method on this post. Thanks for any suggestions!
  22. Just gave this a try today (both adding entries through the CMS and displaying them through the API). Works wonders, no complaints. Props to ryan!
  23. Thanks a lot for making this module, ryan. I've already used to to import over 400 pages... huge time saver. The one suggestion I have was touched on by one or two people earlier in the thread: the importer doesn't work when the page is missing a 'title' field, presumably because it's used to generate the page name. It's pretty easy to get around by making a dummy title field, populating it with a CSV column, and then deleting it after importation, but it would be really great if during Step 2 we could specifiy a column from the CSV to use for generating a page name/slug.
  24. wes

    Hello from Wes

    Thanks for the responses, everyone. The repeatable fields video was awesome.. exactly how I was hoping it would end up working within the interface. Yeah, I agree. I didn't want to hate on WP too much, because what it comes down to is me pushing it towards a task it is not really designed for. It's a blogging platform, but I want to use it for much more. At that point, there are so many plugins I must incorporate, all at (as you say) variable levels of quality and security. It was time for me to move on. You're absolutely right... PW is pure data, without getting in our way.
  25. This. Changes. Everything. Awesome work, Ryan!
×
×
  • Create New...