ryan

Okay great, glad you resolved it. And also glad it wasn't a forum error.

I got an email notifying me of a new post with the title "Page field problem", but now that I get to the forum, I can't find it. Just wondering if whoever posted it was able to solve this problem (and deleted the post?) or if it didn't post due to some error in the forum? I haven't had that happen before, so just wanted to double check.

Great, thanks. I will test some more here and then commit it. Good idea about adding the allowRelative option!

Actually default sorting is already there: 1. Edit the parent page of the children you want sorted in the admin. 2. Click the "children" tab, and then the "sort settings" link. 3. With the sort settings open, choose the field that you want to sort by. Save. Now the results will appear in that order in the admin, as well as when you do a children() call from the API. Of course you can always override it from the API by specifying your own "sort=" selector in the children() call. But the method described above is how you setup a default sort for children of any given parent page. This is how they will appear in the Page List. In my own sites, I use this particular feature all the time. For instance, on news/press items, I always want them reverse chronological according to a date field. In company directories, I sort them by person's name A-Z. And for other pages where I want to control the order with drag-and-drop, I don't set a default order. Let me know if I've misunderstood your question? But lets say that you are sorting by a "last_name" field, and it's different from your "title" field. You want "last_name" to appear in the Page List because it will be easier for you to find your pages that way? 1. Go to Admin > Modules > Process > Page List 2. Set the "name of page field to display" to "last_name title". Save. Now it will display "last_name" in addition to the title for any pages that have that field. For all other pages, it'll display the title, as it does now. You can take this further by entering more field names in that space. This is handy for this theoretical situation, as well as displaying pages with dates (when they have them) along with the title, and other things. Let me know if this helps?

I've got to do more testing, but here's the solution I came up with that I think accomplishes what you want. I added an extra path() function to the Sanitizer class, to handle the relative URLs. Also, the class file is attached (in a ZIP) if you want to try it. <?php /** * Return the given path if valid, or blank if not. * * Path is validated per ProcessWire "name" convention of ascii only [-_./a-z0-9] * As a result, this function is primarily useful for validating ProcessWire paths, * and won't always work with paths outside ProcessWire. * * @param string $value Path * */ public function path($value) { if(!preg_match('{^[-_./a-z0-9]+$}iD', $value)) return ''; if(strpos($value, '/./') !== false || strpos($value, '//') !== false) $value = ''; return $value; } /** * Returns a valid URL, or blank if it can't be made valid * * Performs some basic sanitization like adding a protocol to the front if it's missing, but leaves alone local/relative URLs. * * URL is not required to confirm to ProcessWire conventions unless a relative path is given. * * Please note that URLs should always be entity encoded in your output. <script> is technically allowed in a valid URL, so * your output should always entity encoded any URLs that came from user input. * * @param string $value URL * @param bool $allowRelative Whether to allow relative URLs * @return string * @todo add TLD validation * */ public function url($value, $allowRelative = true) { if(!strlen($value)) return ''; // this filter_var sanitizer just removes invalid characters that don't appear in domains or paths $value = filter_var($value, FILTER_SANITIZE_URL); if(!strpos($value, ".") && $allowRelative) { // if there's no dot (or it's in position 0) and relative paths are allowed, // we can safely assume this is a relative path. // relative paths must follow ProcessWire convention of ascii-only, // so they are passed through the $sanitizer->path() function. return $this->path($value); } if(!strpos($value, '://')) { // URL is missing protocol, or is local/relative if($allowRelative) { // determine if this is a domain name // regex legend: (www.)? company. com ( .uk or / or : or # or end) if(preg_match('{^([^\s_.]+\.)?[^-_\s.][^\s_.]+\.([a-z]{2,6})([./:#]|$)}i', $value, $matches)) { // most likely a domain name // $tld = $matches[3]; // TODO add TLD validation to confirm it's a domain name $value = filter_var("http://$value", FILTER_VALIDATE_URL); } else { // most likely a relative path $value = $this->path($value); } } else { // relative urls aren't allowed, so add the protocol and validate $value = filter_var("http://$value", FILTER_VALIDATE_URL); } } return $value ? $value : ''; } Let me know if you think anything is missing here? I tried to duplicate what you added, and also account for the relative paths vs. domain issue. Thanks, Ryan Sanitizer-php.zip

The only issue I see is that dots can be in page names and filenames. So that leaves the question of whether "company.com" or "sitemap.xml" is a domain name or a relative path/file... This is a problem in the existing url() function too, I'm just not sure how to solve it. I think I'll err on the side of assuming a domain name if the path doesn't start with a ".", like "./sitemap.xml" or "../../sitemap.xml". I like your addition of the allowRelative option. GitHub is great, or forum and/or email is fine too. Whatever you prefer. Thanks, Ryan

Jim, Thanks for posting that screencast. I'm aware of this particular issue, just haven't figured out how to solve it. I usually just move the item below the list, close the list, then move it above. I think this only happens in that specific location (right under the homepage), so it's probably an easy fix, I just need to track it down. This is one of those issues I run into every now and then, but forget about it. Now that I've got a video, I can't forget about it. So hope to have this one fixed soon. Do you have any more details on how to duplicate the other issue that initiated this thread? I still cannot duplicate it, and might need a more literal explanation of exactly what it takes to duplicate it. If for some reason I still can't duplicate it by April, you'll have to show me when we're up there for Hanna's birthday, and hopefully we can fix it then. Thanks, Ryan

A couple more things I wanted to add now that I'm at the computer (rather than the cell phone). There are more details about pagination here: http://processwire.com/api/modules/markup-pager-nav/ There's more information specific to your question under the section called "Are there any side effects?" The other thing I wanted to mention was your use of sorting by "id". The id is not something that you can necessarily count on 100% for sorting, because it's generated by MySQL. For the most part it's probably going to give you the result you want (at least in the short term), but it's also possible that it will be out of order from your other IDs (it all depends on MySQL and whether it ever reuses old IDs). This may never be an issue. But if you want to play it safe, you may be better off sorting by "-created" (date created) rather than "-id". I believe it will give you the same result you are expecting, but without the risk of relying upon a MySQL id.

For the results where you don't want pagination, add "start=0" to the selector. So in total it would be: "limit=10, start=0, sort=-id" (though it doesn't matter what order you place these in)

It should accept paths -- that's the way I usually use it. You may be fine to use the PW InputfieldImage for your file uploads. But what I just wanted to communicate is that it was designed for a different context (an administrative context). So if you do use it, double check and understand what it's doing ... making sure that it's providing the security that you want relative to your server environment. If you see anything that you think should be changed or added to it, of course I'll be glad to upgrade it. If you decide you want to use it, let me know and I will also take a magnifying glass to it and walk through it in the context of non-administrative/anonymous use. Thanks, Ryan

Are you saving images using ProcessWire's image field, or your own? I would recommend using your own, just because ProcessWire's file/image fieldtypes were designed specific to the PW2 admin. Granted it might work well, but it was designed for administrative use rather than anonymous use, and I'd like to certify it for that use before I'd feel 100% comfortable with using it in that context. I'm always paranoid with anything that involves uploading files to a server. I've always felt that a best practice is not to allow anonymous users to upload files to the server. But in lieu of that practice, here's a few best practices I follow, though most are probably obvious. 1. Make sure that anything they upload matches known file types/extensions. Ensure that your extension check can't be mislead, as people will try to upload filenames with two extensions, nulls, dots, slashes, misleading UTF8 characters and other strategies to disguise the real extension. 2. Make sure that the uploaded files go into a non-web accessible location until confirmed that they are valid. If possible, have a real person involved to determine if they are valid. Depending on the context, this may not be possible. But if it is, then do it. 3. When files are ultimately placed in their web accessible location, make sure that no files can be executed in that location. This is just an extra safety measure. For instance, see ProcessWire's htaccess file to see how it disallows some file types from being requested in certain locations. With file uploads, I might only allow files of type GIF, JPG, JPEG, or PNG to be requested from the target dir (assuming the file upload were for images). 4. Convert your filenames to your own format. If there is some id number associated with the upload, use that number for the basename. If you want to retain the user's original filename, then convert it to ascii before placing in the target location. ProcessWire's $sanitizer->pageName() function is a good way to do that. 5. Check your PHP max_upload_size and max_post_size to be sure they are set consistently with the max file size you want to allow. Or, check the file size after upload, and delete anything bigger than what you allow. The max upload size that you can set in the POST vars is pointless from a security standpoint. 6. Be prepared for a million copies of c99.php disguised as other types of files/images.

Sevarf2, Jimyost, Adamkiss, I still haven't been able to reproduce this issue, but I did just make an update that may prevent it from happening in the first place. I modified ProcessPageList so that it doesn't "reopen" a page after moving it. This was done to improve the UI for when you have to move lots of pages. But after making the change, it occurred to me that this might actually eliminate the problem that was brought up in this thread. The only problem is that I can't test it. If any of you have been able to duplicate this issue consistently, and wouldn't mind testing the latest commit when convenient, I'd appreciate it if you could let me know if it has solved the issue or not. Thanks, Ryan

The admin is actually /processwire/ by default. But if you are getting 404s for all the links, that means mod_rewrite probably isn't active/installed with your apache. Mod_rewrite is something you'll find on almost all web hosting accounts, but probably not on a standard os x web server, which I'm guessing is fairly stripped down. I'd say install mamp and you'll never look back... Takes about 2 mins to install, and will set you up with an environment consistent to what you'd find on a web host. ProcessWire requires mod_rewrite, but not all cms's do. Though all will be much better off with it, as you'll be stuck with ugly urls without it.

Thanks! I appreciate that! I definitely agree with what you are saying and that's the strategy I will be taking. The goal is to leave off any features that would be used on only 30% of sites (or by 30% of people). Or, if they are included, then delegate them to optional modules. I'm also thinking that number should become 40% or higher after some time. This particular feature is part of a module (though not an optional one). I'm much more particular about what goes in the core, where I'd be much less likely to compromise on something like this. In this case, it appears to be a 50/50 preference thing (I think Adam is right on this). And if the other 50% feels as strongly about wanting to go back to the list after editing a field, as I do about not wanting to to that, then I figure it's a worthwhile compromise... It was easy to do, and didn't result any significant amount of additional code. Plus, we're a small group of people here and if this was bothering 3 people, I figure that counts for a lot. I'm just glad I'm not the only one that likes to stay in the editor after saving!

I'm one of those people that likes to see my changes reflected after saving, as a confirmation to my mind of what I just did and making sure that's what I wanted to do. It drives me nuts to use software where I'm returned to a list, only to have to wade through the list and go back and edit it again – I won't use a software like that. So this is the planned behavior for the software, and not something I would call an unpolished detail. Actually I think the software is pretty polished relative to it's age (?). That's not to say there isn't plenty of room for improvement, but this is a new project and I'm proud of where we are at this stage. But if there are any details people want to modify, my hope is that they will and submit the change so we can include it in the core. If you grab the latest commit, you can now configure this behavior for the Process > Fields module. To change the behavior, to to Modules > Process > Fields. Click the box that says "return to list after save". Now whenever you save a Field it will return you to the list. The only exception is the first time you create a field, the second screen is mandatory because it often contains configurable details of the field that aren't on the first 'add' screen. If this is desirable to people, I'll add the same option to other Process modules.

There is a filter built in, but you have to turn it on. Go to Admin > Modules > Process > Fields. You should see a checkbox option there to turn on list filters. Now the next time you view your Fields, you'll have a box that lets you limit what fields are shown at any given time.

This is covered on the documentation in the API > Selectors section, but wasn't previously at the level of detail you requested. The possible values depend on what fields you've created (they are the values). But I didn't cover the "sort=sort" before, so that's taken care of now. Here is what I added: How results are sorted if you don't specify a "sort" in your selector In $page->children() and $page->siblings() the results are automatically sorted by the page's default sort field that you specify in the admin. If not specified in the admin, the pages will be sorted by the order they are placed in the admin. This behavior can be overridden by specifying your own "sort=[property]". With $pages->find() and $page->find(), if you don't specify your own "sort=[property]", the results are sorted according to MySQL's text searching relevance. If no text searches are performed in your find(), the results are unsorted. As a result, it is generally a good idea to include a "sort=[property]" when using $pages->find(), especially if you care about the order and your find() operation is not text/relevance related. How to force pages to sort by their admin order with $pages->find() Unlike $page->children(), the $pages->find() function does not automatically sort by the order they appear in the site tree. This is because $pages->find() is not limited to finding pages specific to one parent, so it may be pulling pages from multiple places (according to your selector). If your parent page(s) are not already sorting by a specific field, you may still tell the $pages->find() to sort by the parent's order by specifying "sort=sort" in your selector. This is the same as saying "sort by whatever order I dragged the pages to in the admin." But note that if the results have multiple parents, the resulting order isn't likely to be useful.

AdminBar rocks!

Good points. The "sort=sort" is assumed when you use the children() or siblings() functions. But for find() operations, a relevancy sort is introduced. Of course, if your find() doesn't involve some kind of keyword, then that relevancy doesn't really come into play. I think what may be appropriate is for me to automatically add a "sort=sort" to any find() operations that include a "parent=" portion of the selector. What do you think?

Actually PHP is what the comments system uses for sending email. And it doesn't get any simpler: <?php mail("you@company.com", "Subject", "E-Mail Body"); If you want to send HTML: <?php mail("you@company.com", "Subject", "HTML Content", "Content-Type: text/html"); If you want to include a specific FROM address: <?php mail("you@company.com", "Subject", "HTML Content", "From: bob@company.com"); If you want to do both: <?php mail("you@company.com", "Subject", "E-Mail Body", "From: bob@company.com\nContent-Type: text/html");

I think that both Adam and I are using MAMP on localhost. If you are on a Mac, you may want to try out MAMP too. It's free, and much better than what you get with OS X by default.

Adam has good suggestions, but I just wanted to correct on one point. ProcessWire doesn't care whether it's run from the root of a domain or a subdirectory. It should not matter. I run most of mine from subdirectories on my local machine. What I am wondering is if the "~" might be a problem, as ProcessWire does not allow that character in URLs. Though I can tell you what to change to allow it (it's in the /.htaccess file). I'm just not certain if that's applicable here since the ~michele dir isn't managed by PW. But if you want to give it a try, edit your /.htaccess file, and replace line 29 by adding the "~" character in it: RewriteCond %{REQUEST_URI} "^[-_.a-zA-Z0-9/~]*$" Note I added it right before the closing "]" bracket. If that doesn't help, then try editing your /index.php file and change this line (line #38): $rootURL = isset($_SERVER['HTTP_HOST']) ? substr($rootPath, strlen(rtrim($_SERVER['DOCUMENT_ROOT'], '/'))) . '/' : '/'; To this: $rootURL = "/~michele/process/"; Also add the "localhost" part if that is actually part of the address that appears in your browser bar. I'm assuming that is there as a hostname though, in which case it doesn't need to be included. If that solves it, let me know. This is a known, but rare issue, and I'd like someone to test a fix.

The total count issue is a known issue (per Adam's report). It's a minor enough one that I thought I'd wait till I was working in the ProcessPageList.js with something else, and take care of it at the same time. Jim, thanks for posting this video. This was helpful to see. I have no doubt there is a problem, but I'm running into trouble reproducing it here. I duplicated the exact steps from the video as best as I could (multiple times), but have yet to get a doubled list like shown in the screenshots/video. What am I missing? I've tried in Safari 5, Chrome 9 and Firefox 3.6. Is there some extra click that I need to do at the right time? Is this behavior exhibited every time you move a page with children, or is it only in some instances? I want to fix it today, but I just need to find a way to duplicate it. Thanks, Ryan

I agree. Stay tuned, this one isn't far off.

Martin, sorry I couldn't reply earlier. I was out of the office yesterday. But the solution you found is the right one. This page has some additional information on it too: http://processwire.com/api/types/nullpage/