ryan

Here is the recommended way to do this in ProcessWire (using your example): 1. Create a page: /options/favorite-foods/ (for example). Though call it whatever you want and place it wherever you want. 2. Add child pages: /options/favorite-foods/chocolate /options/favorite-foods/pizza /options/favorite-foods/gum /options/favorite-foods/waffles /options/favorite-foods/ice-cream /options/favorite-foods/donuts /options/favorite-foods/chips 3. Add a new "Page" reference field in Setup > Fields. Call it 'favorite_foods' (or whatever you want) For 'Dereference in API as', choose 'Multiple Pages' For 'Parent of selectable pages' select '/options/favorite-foods/' For 'Input field type' choose 'Checkboxes' 4. Add the new favorite_foods field to whatever templates you want, and you are set. More info: Need to add a new option? Add a new page under /pages/favorite-foods/ Want to do something cool with the template your favorite foods are using? Add this: <?php $links = $pages->find("favorite_foods=$page"); echo $links->render(); That would list all pages that had that particular favorite food selected. Perhaps this is a useful page in your site? Once you get used to the power of creating options this way, you won't want to do it any other way.

Thanks Matt, this is awesome. Thanks for making this new version so quickly. Btw, my comment about the cache was a compliment for your solution. I was comparing to the context of another solution I saw that provided no limits on the number of cached/resized images... thousands of size variations per image could either turn into a DDOS attack or fill up a drive before long. I completely agree about drive space being cheap–might as well use it. ProcessWire works the same way your script does in that it only allows the target image dimensions to be specified by the developer.

That code snippet above wouldn't clone a tree, just a single page. When this is implemented in the API, we'd let it be optional as to whether to clone the tree (i.e. be recursive). But we'd definitely provide that option, just like the delete() function provides that option (though requires it if the page has children). That setIsNew function isn't part of the public API, but it would be necessary in this case to tell PW that this is a new page it should create when it comes time to save. Otherwise the cloned copy would still remember that it was originally loaded from the DB. I can't think of another situation where you would ever need to use the setIsNew function, so that probably won't ever make it into the public API.

Soma this seems like a great solution for when it's needed. Given that PW lets you specify image fields as "fields to show" in the pagelist (in each template's settings), it seems like it should do something like what you've put together here. If you don't mind, I'll implement something similar for when someone specifies an image field to appear in the pagelist.

Pete, since I still can't duplicate here, I'm wondering if there may be some other module involved. What non-core modules do you have installed in PW? Btw, I tried in FF5 not FF6, and IE8 rather than IE9, so will try in FF6 tomorrow, just in case there's something there. Also, can anyone else duplicate this? Thanks, Ryan

Assuming I'm reading it right, I think the only thing that seems different here is the classes you are applying on the opened 'Contact Us' link. What do those classes "dir rtl" mean in terms of how they should affect the behavior of this nav? Thanks, Ryan

If you are starting a new site I would go ahead and use 2.1. But since we're still wrapping up some details, you would just want to test any changes locally (stage them) before pushing to your production server. However, that workflow applies regardless of version or CMS, so if you are using best practices with your workflow then use 2.1.

@MattWilcox–thanks for your posts here. It sounds like the solution you've put together is intended to only send the target image size, rather than the result I was getting (both large & target). When exhibiting the intended behavior, it seems like this would be ideal especially for the situation we were talking about (images in a richtext field). My other concern about a similar approach (from another site) was the security of creating any number of resized images... filling up the drive. But yours only outputs predefined sizes, so that is great. @kunane–given that I recommended this as a possible solution [with reservations] even when I thought we had to live with both images coming through, now I would definitely recommend this solution [without reservations] for the question you had. Here's a few impressions about the different solutions. I don't think I would use both solutions together. If you are using Matt's solution already, I don't think it would be worthwhile to use the <noscript> solution with it because all the JPG requests are already going to be routed through Matt's PHP script (unless you exclude certain dirs). My impression is the <noscript> solution may be one to consider in cases where you have markup control (like in PW templates), already have full image size control (again, like in PW templates), want no server overhead (routing image requests through script), don't want to install anything, and/or want to be able to fine tune the various sizes used in a per-image basis. The <noscript> solution may lose some of it's convenience outside of a system like PW, because you may have to manage the various image sizes manually. Matt's script takes that role if your site is compatible with globally predefined sizes, which could be really convenient. That's my impression based on what I know so far, but I've not used any of these techniques on a production site yet. What are the other situations where you would use one solution over another?

Since you guys need this sooner rather than later, I'll put it higher up in the priority list. Cloning a page will be relatively easy. Haven't tried it, but I think this may work: <?php $cloned = clone $page; $cloned->setIsNew(true); $cloned->id = 0; $cloned->name = $cloned->name . "-clone"; $cloned->save(); Assuming that much works, what I can say for certain would not work is file fields. This is where the process would become more complex than this, though shouldn't be bad. I'm adding this to the to-do queue on GitHub. Adding another tab (like a 'language' tab) to the PageEdit screen is going to most likely involve hooking into the ProcessPageEdit::buildForm function and appending another InputfieldWrapper to the form it returns. Probably best for me to setup an example for this–let me know when you are at the point where you want it and I'll get it going. Thanks, Ryan

The images/files really aren't meant to function independently of a page. All of their ownership comes from a page. As a result, I would suggest maintaining a page for each image, and PW is designed for this. For instance, you wouldn't want an image field to have 1000 images on it because that's going to be really difficult to manage without pagination and such. But if you are using pages as images, no problem. To put it another way, pages can scale indefinitely, but file/image fields aren't intended to at present. As for keeping track of which admin user uploaded a particular image/file, that certainly makes sense. Though it also makes sense with any kind of field. The current plan is that we'll be keeping track of this stuff with a page revision manager and logs, so that you can have a history of all page edits and be able to see where every edit came from (and revert to it if you want). This is actually already functional, but hardly production ready so I'm continuing to work on it and targeting it for v2.3. Be cautious dealing with public data input, especially files. PW isn't designed to have it's admin tools exposed to untrusted users. The needs for anonymous/public data input are different from admin input. For instance, image uploads really need to have original files quarantined (not web accessible) and only processed/resampled versions of images web accessible. Yet this would be a counterproductive approach for admin needs. PW's fields are designed for administrative and trusted users. Uploaded files go right into the /site/assets/files/ directories and not into a quarantine area. As a result, when I'm implementing some kind of public file upload on a site, I usually write the code for that with security specific to the need–it usually involves a quarantine area and babysitting the uploads.

I think that makes sense. If they've specified certain child templates as allowed in the template settings, then I think it should follow what ever order they've specified. Whereas alpha order makes sense if they haven't specified anything. But since the order is sortable in that part of the template editor, we might as well retain it. I've added this to the GitHub issues list. Thanks, Ryan

Those tabs are being generated by javascript from the existing markup. The tab label appears in the 'title' attribute of markup like this: <li class='InputfieldWrapper ui-widget' id='ProcessPageEditContent' title='Content'> As a result, I would maybe suggest a search: id='ProcessPageEditContent' title='Content' Replace with: id='ProcessPageEditContent' title='Inhalt'

I think we'll have to build a module to provide this functionality in the near future (or include it as a configurable option in the PageEdit module, if necessary). I've run into the same need a few times when adding a bunch of pages. It would be nice to just create one right after the other. At the same time, I don't really like having a control like that permanently fixed to the interface like it is in modx. So I think we'll make it something that the powerusers can enable when it suits the need.

Glad you got it working. It's pretty unusual for a webhost running PHP5 to not have JSON support, as it's part of PHP's default installation–they would have to specifically disable it. But I know there are some that install PHP and basically exclude everything possible... that usually means bigger problems than just missing JSON support. There are workarounds for missing JSON functions. You can always define your own json_encode/json_decode functions and solve the problem that way. A good JSON library is the one included with the Zend framework. Years ago I dealt with a client's server that didn't have JSON support, so used Zend's framework and created the functions that way. It works, but much better to have them native in PHP (faster running).

Thanks Pete! I did the same thing before our little one arrived–got as much work done as possible. My work hours pretty much got cut in half afterwards. But it's definitely worth it. I just like to keep up with the forum as much as possible. I don't like killing anyone's momentum by making them wait days for an answer on a simple question. Luckily I've got a few minutes at the computer this morning, so hoping to get caught up.

Several new messages I want to reply to came in since Friday night here. Apologies I've been unable to reply yet. My wife and daughter are very patient with me during the week, but don't like me near the computer on the weekend. So I've been reading on my phone but can't properly reply till back in my office at my computer. So thanks for being patient with me this weekend and I'll reply by Monday (or tomorrow if anyone takes a nap at my house) I just didn't want anyone to think I was ignoring their message--my computer access is just limited on the weekend, some weekends more than others.

Sorry I haven't actually made it back to computer yet, just on cell and hard to type on this looks like I've got lots of msgs to catch up with hope to get back in office later today to catch up

Looks cool–I will reply a bit later, getting called to dinner.

I see what you mean about those class names. I had forgotten those class names were generated dynamically from the text labels. We will need to change that for future localization, so I went ahead and changed it now. If you grab the latest commit, it now keeps the label used for generating the class name in a separate field in the JSON so that you can safely change the 'name' one on the fly.

I'm pretty much getting the same result there. Clear cache and cookies, open tiny browser to the other demo URL. First load is a big 1-megabyte image. Hit reload and it's is a smaller 78k image. First and second load screenshots attached. Are you getting a different result? I was confused by your screenshot, because one of them did show the 205k image as being loaded, so wasn't sure what you meant?

I tried in Firefox this time with Firebug. Cleared my cache and cookies. Then loaded it, ensuring the browser window was as narrow as it would go ahead of time. Got something really interesting this time–830k for creepy.jpg! Not sure what that's about? That can't be right. Maybe a typo by Firebug or am I reading this incorrectly? (see 1st screenshot) Reloading again gets me the normal 205k image (2nd screenshot). My browser window was set at the smallest width it would go the entire time (see screenshots).

Just in case you need it more specific, here's an example of the JSON output (pulled from Firebug). I underlined the Edit, Move, View, and New, so that you can more easily see what's around it. {"page":{"id":2,"label":"Admin","status":1039,"numChildren":6,"path":"\/processwire\/","actions":[{"name":"Edit","url":"\/celist\/processwire\/page\/edit\/?id=2"},{"name":"View","url":"http:\/\/localhost:8888\/celist\/processwire\/"},{"name":"New","url":"\/celist\/processwire\/page\/add\/?parent_id=2"},{"name":"Move","url":"#"}],"addClass":"PageListAccessOff","type":"System"},"children":[{"id":3,"label":"Pages","status":21,"numChildren":8,"path":"\/processwire\/page\/","actions":[{"name":"Edit","url":"\/celist\/processwire\/page\/edit\/?id=3"},{"name":"View","url":"http:\/\/localhost:8888\/celist\/processwire\/page\/"},{"name":"New","url":"\/celist\/processwire\/page\/add\/?parent_id=3"},{"name":"Move","url":"#"}]},{"id":22,"label":"Setup","status":21,"numChildren":3,"path":"\/processwire\/setup\/","actions": ... and so on...pretty isn't it? In your case, you may want to target strings like: "name":"Edit"

You are right it is generated by javascript, I wasn't thinking about that. But it's delivered to Javascript by ProcessWire in JSON format, and that JSON should still pass through Page::render. So in this case, if you set your replacements like "Edit" and "Move" – including the double quotes, I bet that will work. Let me know?

The 'Move' and 'Edit' issue are likely the same thing. Because those terms appear elsewhere in other contexts where it shouldn't be changed, you have to adjust your string to ensure you are only targeting the right version. For instance, with 'Move' and 'Edit', you may want to change them to be '>Move<', and '>Edit<' so that you are only replacing those strings when they appear in a markup tag. You may need to take this approach with most terms. Make them as specific as possible just to ensure you are only replacing the things you want, and nothing that you don't.

My experience so far is that this method doesn't save any bandwidth, it actually increases it. Here's one way to test: 1. Open Chrome (or Firefox, or any browser where you can monitor activity). 2. Open the browser activity window. In Chrome that's: View > Developer > Developer Tools > Network 3. Size your window to as small as you can, to ensure it targets the smallest image size. Then load responsive-images.com. 4. Watch your activity window. Notice that the browser downloads both the large 205k image (/content/images/creepy.jpg) and the 26k thumbnail (/content/images/thumbnails/thumbnail.jpg), even though only the thumbnail is ultimately displayed. 5. Click in some of the other thumbnails and notice that only the large image is loaded (though seems like they could fix that part though, since it's JS driven). Try loading the site on your mobile device (outside of wifi) and notice how long it takes to load–it appears be loading the 200k image, though no activity window to confirm it on my iPhone. The reason it loads both the large and small is because the browser starts downloading the large image as soon as the <img> tag appears, before JS can change it. My impression is that there is no way to avoid consuming the bandwidth of the image present in the src attribute of an <img> tag, unless it's contained in a <noscript> tag.