ryan

Glad you like it. I implemented that on Friday , per your earlier request to have them differentiated–good idea.

I can't think of any reason why those characters would need to be entities in UTF-8 output. I'm guessing you are talking about a TinyMCE field, so that's what is determining what should be made into entities. On other text-based fields, you can select what text formatters you want to apply (including entity encoding). However, since we're using UTF-8 I don't think that the characters you indicated would ever be entity encoded, though I could be wrong.

Thanks Pete that's a good find. From what I understand here, it looks like jQuery normalizes it into e.which, and that's all that we'd need to check? I will give this a try. It sounds like the ui.keycode stuff is just translations of common keycodes, but useful nonetheless.

That is exactly what I'm looking for, but the problem is that event.keyCode is not cross browser, from what I understand. Apparently this even changes between versions of browsers (including Firefox, not just IE). It's one of those things that seems a little too ambiguous with browser and versions so I've been avoiding it. I did experiment with adding a form submit event on focus (that returns false), and removing it on blur. This seems to work okay and might have to implement it like that, but this is one of those things that I worry will take a few commits before it's right.

ProcessWire doesn't have any special requirements as far as hosting goes, so the truth is that it'll run anywhere that WordPress or Drupal runs, and that includes pretty much all hosting providers. I've been really happy with http://servint.com and that's where I keep all of my own servers and those of my clients. They are VPS and dedicated server provider. They are far from the cheapest (their least expensive is $50/month, which is what I'm using), but they are extremely reliable, helpful and there is no grey area. So if looking at a VPS or dedicated server and don't want to deal with undisclosed limitations, this is definitely a good place to check. I've used their service for nearly a decade and it's been rock solid. I've also been looking at cheap hosting lately, and am testing an account with hostgator (http://processwire.org is running there). Seems to run nicely, and I like that they are using cPanel and have shell access for an account that is under $10/month. I've not yet tested it under any kind of load. But like all low-budget hosting providers, I recognize that as soon as traffic gets heavy or load rises, throttling would be introduced. If you have to contend with any kind of traffic or load, then you do get what you pay for with hosting. If you don't have to contend with those things, then budget hosting like hostgator, bluehost, hostmonster, and the others are perfectly fine. Personally, I would never pay for an account without shell access, but that's me. I consider this an absolute requirement, but ProcessWire doesn't. Most of our traffic on this site is from Europe, so I've sometimes wondered if I should move the hosting to Europe. Currently the site is hosted at ServInt in their Washington, DC data center. Works great for me, but I'm one of the few US users. I would be interested in hearing how the site performs for those of you in Europe and outside the US.

While it's true that we could all use a little more sleep, I don't think that'll solve the problem in this case. 8) We need a more detailed error message. Take a look at what's the last entry in /site/assets/logs/errors.txt and paste it here. Or edit /site/config.php and set debug to true. Also, can you remember what the last edits that you made were? Did it involve moving pages or changing templates? Did you recently make any changes to the templates or fields used by this page? If so, please describe the changes that were made.

For all those that have submitted stuff, major thanks for all of your votes, reviews and comments at these sites. Pete thanks for the great, thorough and thoughtful review over at Alternativeto!

That is a valid page name. Periods "." are an allowed character in ProcessWire page names. That's how we allow for page names like: mypage.html You can create page names like that in the API. But PW tries to beautify it by removing ugly combinations like that with some JS on the front-end: // remove ugly combinations next to each other name = name.replace(/(\.-|-\.)/g, '-'); As you noted before, that beautification can be skipped by just hitting enter in the 'name' field to save the page. I'm guessing that's what they did? At that point, it goes to PW's pageName sanitizer, which is less restrictive and doesn't try to beautify or translate it… just make it valid. I would like to find a way to prevent the enter-to-save in the pageName field though.

Great job ffub! Nice work with the code and documenting how to use it too. I will add to the modules directory asap. Thanks for your work here. I will definitely be using this module in the future.

For FancyBox, I would suggest installing and configuring per the directions here: http://fancybox.net/ FancyBox is a good one, but there are plenty of others too, so it's good to look at the options and see what suits your needs best. I usually keep my admin and front-end scripts separate so that I can upgrade PW with out considering specific sites, and I can upgrade things on my sites independently from PW's admin. So while it may be technically more efficient to share the same scripts between your site and admin, I think long term it's a smarter thing not to. So my recommendation is to install FancyBox (or another lightbox) on your site in the same manner as if ProcessWire wasn't there.

Glad to hear you are working on this one again! The only page that will have that process is the actual Trash page. I think you are trying to detect this instead? (the current process being executed?) if($this->process != 'ProcessPageTrash') { However, I'm not totally sure that identifying whether the current Process is "ProcessPageTrash" is useful to you? It sounds like you are trying to detect someone manually deleting a page in the trash. I'm wondering if you might want to use $page->isTrash() instead? You can call isTrash() on any Page object, and it'll return true if the page is in the trash. I agree with Soma that it may be accounting for something I wouldn't expect to be accounted for. If something is in the trash, I suppose I'd assume that it's not still being managed by any other systems. However, you are right that it is possible for someone to go and permanently delete a page in the trash without emptying the trash, so if it's a situation you think needs to be accounted for, I'm sure we can figure out how. I'm thinking that isTrash() may be what you were looking for, but let me know if not...

Took a brief look in the code and it doesn't look to me like you are outputting it at all. Any Process module automatically gets any CSS or JS files with the same name included, so it's ProcessWire that's doing it, not ProcessRedirects. ProcessWire does that because it assumes Process modules aren't autoload. It's unusual for a Process module to be autoload, though it makes perfect sense with ProcessRedirects. So the best solution is to just work around it and use a different name for the CSS file (like styles.css) and add it manually, i.e. $config->scripts->add($config->urls->ProcessRedirects . "styles.css"); Not an urgent thing by any means. I will submit a pull if the need comes up here before you get to it. Thanks, Ryan

It's been a long time since I've purchased a new PHP book. The old ones continue to work pretty well. PHP.net (and google) are my main PHP resources these days. Attached is a photo of the books I have, but I think most of them are probably now outdated. But I would think that any learning PHP5 book on Amazon with lots of 5 star reviews would be a good way to go (that's how I bought most of mine anyway). By no means should you need as many books as I have... I just have an unhealthy habit of buying lots of books for any tool that I use. PHP can too and it's especially good with command line scripts (which ProcessWire will also do). But for building windowing applications with PHP, you need to use a library with it (and I've not used it before). PHP was a language originally designed specifically for the web, so it's use in native applications that are non-web applications is probably not as strong as other languages that were designed pre-web or for other purposes. But I also think that is one of PHP's assets, in that it really is a pure-web language. Not sure I understand? Can you re-word? That's correct. It is possible to break image/file links in that manner. Though my experience has been that it's rather uncommon in real life scenarios. Down the road we'll have more modules to babysit these things, but for now ProcessWire is kind of like a file system. If you delete a file, then any symlinks to it are broken. If you are pulling images from other pages, I usually recommend having a 'shared assets' page that you would use for shared media and use care when deleting things from your shared assets. But note that we will eventually track assets behind the scenes to provide warning messages when you are deleting something that may be referenced elsewhere. We will have built-in support for translation in the admin before the end of the year. Also I think you are right that there should probably be a link in the admin so I will make a point to add that in the near future. Thanks, Ryan

In response to the above, and your previous message: One thing to note about PageListSelect (and PageListSelectMultiple) is that they are using the ProcessPageList. We don't have a dedicated Inputfield type for selecting a hierarchy of pages, so we're piggybacking onto PageList instead. It was originally only designed for PageList and required single selection (like parent page). In the future I'd like to build a dedicated Inputfield type that could be customized and tailored according to individual needs. But this was one of the more expensive things to develop and I built it the best way that I could afford to. It's not perfect, but I think it's a good compromise and the the best I could do with the resources I have. Since I generally have to dedicate my resources to those that will ultimately be used by my clients, there are some aspects in PW (like this inputfield) that are tailored more towards myself and my clients more so than the broader audience. In my case, I needed to make sure my clients unselects were purposeful rather than accidental. So by intention it takes the same exact effort to select a page as it does to unselect one. And there is no template selection support in the PageListSelects because it's a rare need that doesn't exist in my own projects, it's not part of PageList, and I couldn't yet justify the cost in time it would take to add it. I agree it would be better to provide more options for all these things in the future, and as PW's audience grows I'll be able to rethink some of these things and put more resources towards them. But until that time comes I'm really focused on making the "big picture"–the foundation and core of ProcessWire–as strong and powerful as possible, and for as broad of an audience as possible. We'll get to the finer details of lesser used components with time. I'd eventually like to split off the PageList Inputfields from the PageList so that the Inputfields can be customized much more, and we'll probably be looking at that in 2.4 (if someone doesn't build one before that).

For the page that's selected, the 'select' link is replaced by 'unselect'. When you click unselect, it will make it unselected.

Okay that makes sense why ProcessRedirects.css would be there–that module is unique in that it's an autoload module, but it's also an admin process. I've added remove() and removeAll() methods to the FilenameArray class, so if you grab the latest commit they should be there. Antti–next time you are making updates to ProcessRedirects, if you want to make it only populate ProcessRedirects.css when it's needed, I would just rename ProcessRedirects.css to something else, and then manually add it to $config->styles at the same time you are creating the output for the page where it is used. This is something I hadn't considered before since Process modules automatically load their related CSS/JS files, but it will be easy for us to get around it.

PageListSelect and PageListSelectMultiple work differently from all the others. Since they support a hierarchy, the parent represents the starting parent rather than the only parent. Also, templates aren't applicable with the PageListSelects... they don't deal with templates at all, only parent. Likewise, the "custom code" option isn't applicable to the PageListSelects either. May add these options down the road, but just wanted to clarify that the PageListSelect inputfields are a different beast than all the others which are flat and non hierarchal.

Unless you know the templates (or parents) used by the children, I think Antti's suggested method is best.

I hadn't planned on per-tab access control, though I suppose it would make sense with field-level access control since tabs are defined as fields containing other fields. Items under children, settings and delete already have granular access control, so worry a little about confusion from bringing in tab access control. But will give this more thought and consideration as we get into development of field-level access control.

It's a good idea and I've had the same need–will plan to add this (likely in 2.2). [edit: fixed my typing, I'm terrible at trying to reply using the iphone]

ProcessWire assumes that the entire /site/assets/ structure is writable. As long as PW can write to any directories in there it should be happy. What you have to do to make that writable depends on the server environment. If Apache is running as your user account (like PHP as a cgi) then it only needs to be writable to you. If PHP is running as a module on Apache (as is most common) then that directory needs to be writable to whatever user PHP is running as. In a dedicated environment or a reasonably secure server environment where accounts are well jailed from each other (as are many major hosting providers) 777 (drwxrwxrwx) on those dirs ensures PHP can write to it without you having to determine what user PHP running as. This is the default that ProcessWire uses for the directories it creates in /assets/ (according to the predefined setting in /site/config.php). In a less secure hosting environment where accounts aren't well jailed from each other, it's preferable to use PHP as a CGI and use permissions where only your account can write to the /assets/ directories (and likewise update the permissions in /site/config.php). But that's for long term. When you are running into write errors in /assets/, do what you need to do to get it working, then determine if you need to lock it down further.

Thanks scarota, I have updated the original post for that fix. To update the description, you first need to get the file that was added. If you just added it, you could use the last() method: $file = $page->files->last(); Once you've got the file, you can set it's description like this: $file->description = 'the description'; Remember to save the page.

Thanks to all that have taken the time to submit ratings! In addition to the nice homepage exposure at alternativeto.net, we're also rated #1 at opensourcecms.com (for the moment anyway). Please keep it up–this will really help the people that would benefit form PW to find it more easily. The pages where you can vote are here: http://php.opensourcecms.com/scripts/details.php?scriptid=561&name=ProcessWire+2.1 (we could also use text-reviews here if anyone has any thoughts to post) http://alternativeto.net/software/processwire/ Thanks! Ryan

Tiltviewer is pretty amazing.

What are you finding in $config->styles on the front end of your site? It should be empty. But I suppose it's possible an autoload module is putting something in there. Just curious what. There hasn't ever been a reset() method in FilenameArray (used by $config->styles/scripts), at least not that I am remembering. I probably wouldn't use that term to clear an array just because the reset() function in PHP means to reset to the beginning rather than to clear. But I will be happy to add such a method to the class. I will call it removeAll() for consistency with other classes in PW. Can you confirm that this is what you need?