adrian

Thanks for giving me yet another tool to try Just when I was thinking about switching from ST to Brackets I have another option to try. Have you guys seen this: http://blog.brackets.io/2013/05/31/better-javascript-debugging-with-theseus/

I just set up a page field with parent of Admin > Access > Users and it works fine. Do you get that error when saving the field in the admin, or a page with that field on it, or saving the page via the API?

But not easy

I think we were at least all on the same track regarding the issue with id and %= On the either / or issue - I really can't wait for this, it is one of the very few things in PW that are sometimes a cause of frustration because it not only feels dirty combining more than one page array, but also because of the issues regarding pagination when you do end up doing that. Nice examples there teppo

Thanks for the link teppo, but none of the examples that David or myself have posted here are of the either/or ilk. Just to spell it out, id|name=1|about would be the same as: WHERE id=1 OR name=1 OR id=about OR name=about An either/or would maybe be: WHERE (id=1 AND name=home) OR (name=about) It's late here, so maybe I am not thinking straight, but I think I am on the right track? That said, I am not exactly sure what David is wanting to achieve with the a|b=c|d style selector. Maybe he is after an either/or, even though that's not what it currently does. I actually don't think I've seen this style documented anywhere either, but maybe it is just assumed to be obvious based on what else you can do. I might sign off now before I confuse anyone else

No problem. PW is incredibly flexible - more so than probably any other CMS/CMF, but it does require that you learn at least some basic php. Mostly foreach and if/else will get you going. I would definitely recommend googling a few tutorials on the possible options/rules for these statements so you can better understand the syntax. It can seem a little confusing at first, but once you get a handle on the basic rules, it really is pretty easy!

Not exactly sure what you are still having problems with, but this line: if $page->parent->name=categories { needs to be: if($page->parent->name=="categories"){ Same goes for the years if statement. Does that fix things for you, or are there other problems?

I thought that too, but then I noticed that: id|name=1|about returns Home and About and: id|name=1001|about returns just About. Is it possible that Ryan has introduced partial/unannounced support already, or am I missing the point?

To be honest I haven't actually used that module until now. I am also having issues with the selectors you are trying, but the following all work fine: path=/about/ id=1,path=/ path%=/about/ I think it is logical that %= wouldn't be supported for id, although I can see the issue when you're trying to combine OR's like that. Not sure if that really helps, but I am sure Ryan or someone else more familiar with that module will chime in soon.

You need to install the PagePaths module which is included in the Core, but not installed by default. http://processwire.com/talk/topic/4874-what-does-page-paths-module-do/

2.4 should probably still run on 5.2.17, just not officially supported. http://processwire.com/talk/topic/5543-processwire-24-possible-to-run-on-php-533/?p=54099 Maybe try contacting renobird (from that post) about his setup with 5.2.17. Also, this from Ryan: PS You can always get an older release of PW here: https://github.com/ryancramerdesign/ProcessWire/releases

It really does sound like PDO isn't running on your server. Have you double checked your phpinfo output or done a php -i from the command line and confirmed that you see something like: PDO PDO support => enabled PDO drivers => sqlite, mysql pdo_mysql PDO Driver for MySQL => enabled

I think basic dependency support has already been committed: https://github.com/ryancramerdesign/ProcessWire/issues/359

Did you play with other operators other than "="? Brown != James Brown, so try ~= or %= depending on exactly how you want the matches to work. More info in the intro post: http://processwire.com/talk/topic/1654-module-pages-web-service-servicepages/

From my understanding, the version of FormBuilder that fixes that issue is 0.22, which is available from the forumbuilder forum: http://processwire.com/talk/topic/1844-form-builder-updates-022 That link won't work if you don't have access to that support board. If you don't have access yet, you should PM Ryan and he will set you up. Once you do have access you should post all future support questions to that board as Ryan prioritizes his time to get those answered as quickly as possible. PS Welcome to PW!

Hey Pete - agreed signatures are currently horrible, especially when people insist on embedding images in their signature, rather than writing them in HTML with a linked image, often resulting in every email from that person having the image show up as an attachment depending on the combination of the sending and receiving email client and settings. My biggest beef is Mac Mail's displaying of images/pdfs inline in the body even if they were added as attachments. Just my opinion, but I think Outlook and others got this right, but I am ranting now

Hey - that's what I suggested in post #5 above I just typed it as PageSelectlist accidentally! Anyway, glad you have it working now. EDIT: Looking at that other post, I think I finally understand things. If you are not actually ever changing the value of this field manually, you could also just store the page ID of the article in a simple text field. You might even want to make it a hidden or locked field.

Glad you got this sorted out! Just a thought - you might find: nl2br($page->get($options['markerTitleField']) better if you want to preserve those line breaks in the output.

Ok, this is a really quickly assembled update. It adds an option to determine whether embedded images will be added to the body field of the page or not. This seems to work great but would appreciate you checking it, especially from different devices / email clients. At the moment this setting is site-wide, but it might potentially make more sense to have it for each email address / category. The other change will hopefully fix that ghost image you had, although I haven't been able to replicate it at my end, so haven't really been able to test. Please let me know if it fixes it for you. My forked version

Sorry, I am still quite confused about the use of this field. I think if you could provide some more details of your exact scenario we might be able to better help.

I would suggest changing your input field type (on the page field's Input tab) to PageSelectlist. It is going to be an impossible user experience for someone to scroll down through a select with 23559 items, let alone 293363 items. Another possibility might be to a Page Auto Complete input field type. This is included in the core modules section, but must be installed before it will be available from the Page field's input tab. Try those and let us know how you go.

Nasty space at the end of the URL is breaking it!

Good to know. So that image named "1283" in the images folder is something extra, rather than an image that you emailed that was somehow corrupted then?

Here is a cleaner function based approach to this: http://processwire.com/talk/topic/5397-assigning-fields-to-repeaters-with-the-api/?p=52123

Just to wrap this up, here is a function that should do everything needed to set up a repeater and assign fields to it: http://processwire.com/talk/topic/5397-assigning-fields-to-repeaters-with-the-api/?p=52123