ryan

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?

Minor typo in my prev example, it should be if(strlen($value) < 4) unset(...

We could use a favicon, and I've actually been working on an icon of sorts, but havent settled in it yet. For variation of admin/site/theme design, I'm relying on the community to build new admin themes and Soma has built a nice one called teflon that you may want to check out. Over time I'm sure more variation will continue to evolve throughout. With languages I was meaning to use the terms coder and developer synonymously. When you want to investigate a language, tune out the noise and then look at what's been built with it. Folks who get hung up on languages are not the ones who make things happen. So if somebody is really defensive about their language choice, be that Ruby, PHP, Python, etc., don't listen to that person. Likewise if they are condeming about someone else's language choice, don't listen to that person. Instead, go and code--build something cool or make something happen. And let the amateurs debate languages. Ultimately it's the coder that matters. When a coder doesn't matter, they must compensate by becoming a language critic. Glad you like the name ProcessWire. I like it too. So that makes at least two of us

I'm wondering if it was the browser cache? That's the only thing I can figure. Though i regularly use the same filenames and haven't run into that before, but will try here again. Are you using PW 2.0 or 2.1? And what web browser?

PW already removes stopwords from the query (and I think that "by" is one of them). Take a look at the %= operator as that works the same as *= but has no stopword or length limitations (at the expense of being slower). But using Adam's example (which is a good one), you could recode that array_walk part like this: foreach($queryArray as $key => $value) { if(strlen($value < 4)) unset($queryArray[$key]); } I've never used array_walk before, and dont know what the error you got is, but I think the above would do the same thing.

Edit your /site/config.php and locate the line that says $config->advanced = false; Change it to true. Now when editing our template, you'll see a "system" tab. Click on that tab and check the box that says to show the name field on the content tab. Save. Your name field should now show on the content tab for pages using that template. You don't want to keep $config->advanced on as it's meant for PW core/system development rather than regular development, and it can get you in trouble (I always keep it off unless I need something in it temporarily). So go back immediately and edit your /site/config.php and set advanced back to false.