ryan

Not currently, but will keep this in mind for a future version.

I'm not sure I understand: a module that removes rooms for tourists? I don't get it. I have a feeling the link would answer it, but it doesn't seem to work (got a 404).

This is on the list for 2.3, so should be coming soon!

I've been working on a blog profile that we can have as an installation option for ProcessWire. The goal is to have a profile that someone could download and setup a pretty nice website/blog without having to touch any code (i.e. it's ready-to-run and populate). I'm hoping that this is something that may help us to grow our audience beyond the web development community. The requirement is that it must be as easy (or easier) than WordPress, both to install and use. This profile is also for web developers, as it's a blog profile ready to be styled and enhanced -- a good starting point. It uses the Zurb Foundation CSS framework, so it is fully responsive and mobile-ready. It's not much to look at now, but should be fully functional. I'm making progress and wanted to post a preview. The content you see here is from one of my client's blogs and the content is just here to test things out. http://processwire.com/blogtest/ I'm hoping to get this up on GitHub next week. I've never really done much blogging, so am seeking feedback on what others would suggest to make the blog profile as good, powerful and simple as it can be. Right now it's pretty much a generic Zurb Foundation "look and feel", so it probably needs at least some color tweaks and integration of some masthead photo(s) or something.

Great module Diogo! Tested here and seems to work well. I did have to change the selector to "$field.status<1, include=all". I did "<1" rather than "=0" so that it would catch comments marked as spam as pending too. In your getModuleConfigInputfields I recommend removing the "size=200" attribute, as that's causing an overflow issue in Chrome/Mac at least. I would just leave off the size attribute there (unless you need it small), as it'll automatically size to the screen width if you leave it out.

Once PHP 5.4 is pretty mainstream (later this year?) we'll drop support for PHP 5.2 and then use PHP 5.3 namespaces. But lots of folks are still running on PHP 5.2 (including me on a few servers) and I don't see any way to be backwards compatible with PHP 5.2 once we start using namespaces. Still, I'm anxious to get them in the PW core and just trying to find the right time when it'll help more people than it will hurt.

Something that is storing images exclusively on another server probably needs to be a different animal from the existing image/file fieldtypes. Rather than trying to hook into functionality there, I would go and create a new fieldtype so you can start fresh. On the other hand, if the goal is to just keep a copy of any files used at the other server, and then replace references to them at runtime (like when output formatting is on or something) then I think that would be more of a scenario where hooks would be useful.

JS is certainly an easy way to accomplish it for helping the editors. It's more the developers I'm worried about, coding in a manner that expects a field to always be populated, when it may not be technically possible for that to always be the case. But if it's just helping the editors that we need, then that's no problem: there are no technical challenges there.

Not sure about this one. Another user had requested that we add that str_replace(' ', '%20', $filename) in the past because it apparently wasn't working without it on filenames that have spaces (and that's why it's there). Sounds like this behavior may depend on the environment. I would never think to use spaces in filenames for anything like this, so can't say as though I know exactly how to tailor this to everyone. But I've added another check in there and pushed it to the source. Though not sure if this will help in this particular situation or not. Either way I recommend avoiding filenames with spaces as that's not very portable. But give the update a try and let me know if it makes any difference here.

Not sure that I understand exactly, but if $_POST is empty, then ProcessWire also won't be able to get at any of the posted data. So I would look to find why $_POST is empty (from a redirect or incorrect <form method> attribute?) before getting into the ProcessWire specific stuff.

Yes, always sanitize anything that gets sent to any API call. If you don't, then anyone can inject anything into that selector just by specifying it in your signup_name field. While I can't think of a major problem that could occur with that in your example, it's best to prevent any injection situation. The stakes may be higher in another situation. That's because selectors are designed for your use, not the users. API calls run as superuser, so it's feasible that in some scenario a hacker could exploit an unsanitized selector. You can't modify data with a selector, so it's not at the same level of concern as something like SQL injection, but still a good idea to sanitize anything getting sent to any API call. Except for $sanitizer API calls of course.

I just updated the Input class so that you can now unset URL segments. Use the existing $input->setUrlSegment($n, $value); function, but specify null as the $value for the segment you want to unset. When you do that, it'll unset the segment and reindex. For instance, lets say you had page /about/products/a/b/c/ where /a/b/c/ are the URL segments 1, 2, 3. If you call $input->setUrlSegment(1, null); then /b/c/ would be segments 1, 2 (and no more 3).

Soma that's not the correct behavior. The segment of a page that actually exists should never be included as a urlSegment. urlSegments are just the extra segments in the URL that didn't resolve to a page. I'll add this unset function to the $input.

Make sure you do this before putting $username in your selector: $name = $sanitizer->pageName($input->post->signup_name); $u = $users->find("name=$name"); While you don't want to have that directly in your selector either way (since it would be unsanitized), I just wanted to add that when you are dereferencing object properties in a string, it's best to surround the statement with {}, like: "{$input->post->signup_name}"; and that should solve the problem.

Thanks for the post Alan. Unless I'm misunderstanding, you shouldn't need to use the 'hidden' at all, as an unpublished page isn't going to be showing up on the front-end site or navigation either way.

Proper required fields aren't quite as easy as they sound in ProcessWire. There are some problematic scenarios. For instance, what if you edit a published page, make a bunch of edits and leave a required field blank. When you save, if there is a missing required field, then logically the save should be aborted. But any other changes you made that were valid would also have to be aborted, otherwise we'd have a page in a partially saved state (which is not possible). A page can't be in two states at once. And if we're saying we support real required fields, we can't have a published page in the system in a state where one of the required fields is blank. So the required field support you see in PW right now is not much more than symbolic, because the page can still exist without a required field populated. PW will complain and give you errors telling you about it, but it can still exist. Real required field support means letting a copy of a given page exist in some unpublished/draft state, until the requirements are met. Once the requirements are met, it can replace the published page. Until versioning is built in, making this happen is overly complex. So until that happens, any required field support will likely just be symbolic required field support via javascript or PW error messages. People will still want to code their templates to account for empty value situations, even on required fields. That's the primary reason why the 'required' option is hidden in advanced mode, because I don't want to imply that you can always expect some field to always be populated. Another scenario that not even versioning can fix: lets say you have a site with a bunch of active pages in it. You add a new field to a heavily used template and make it 'required'. All the existing pages will have an empty required field. It's a tricky situation. The expectation of required fields seems to open more potential for site-breaking situations. Better to code things as if required fields didn't exist.

I've been offline for the weekend since Friday, sorry to be stepping into the conversation late. I'll be happy to implement an unset function for url segments, but wondered if it should just unset, or should it also reindex the url segments that are remaining? For instance, if you have both urlSegment1 and urlSegment2 set, and you unset urlSegment1 should urlSegment2 take the place of urlSegment1?

$_SERVER['REQUEST_URI'] isn't filtered, at least I don't think it is. Just trying to protect against any possible request injection into the logs.

Also you can always change the parent from the settings tab of any page.

We use PHP built in JSON functions for speed and efficiency. PHP 5.4 adds two new options to json_encode for unescaped UTF8 and "pretty in print", so I think PHP 5.4 will solve this and I will implement a version check so PW takes advantage of it.

Thanks for your review! Sounds like a great endorsement for this service. I hope to get the opportunity to try it sometime.

PW should support all current generation browsers: FF, Webkit, IE9 (and IE8 for the most part). I don't see any prob with supporting floatable fieldsets (I'd forgotten we didn't already), so will plan to make any needed updates to support that.

Output formatting always needs to be off when creating/saving pages. The beautification it does here is just the basic stuff that most of the time you don't want in URLs (like double dashes, adjacent punctuation, etc). Setting it twice is just an override for those rare cases when you really do want an unusual char combination.

In this case you would just be adding a new Page fieldtype (called something else) leaving the existing one as is. Then you'd edit your field (in setup > fields) and change the type to the new one you added.

Thanks for posting, this implementation looks pretty cool. I think Drupal lends itself particularly well to this sort of thing given that it's a markup generator where there are a lot of known factors both in structure and markup. What I usually think of as a disadvantage becomes an advantage with this sort of thing. It seems like a natural progression for Drupal as the admin side often is just an extension of the front-end already. I would also like to see something similar in ProcessWire at some point. But as a fun module useful for specific situations, not as a recommended way to edit most content. Inline editing is eye candy rather than something that's actually positive for the online experience. It really sends the wrong message when it comes to content portability and accessibility. Editors need to be focused on the content, not "this viewport." It goes against the nature of markup and regresses one back to thinking on print terms. I can see one of my clients trying to put a line break in the headline to make it look the way they want it, and then ending up with what looks like an error on mobile and feeds. That's just the tip of the iceberg. It also means you are no longer editing an an environment designed for editing. A place ideal for viewing and one ideal for editing may be very different places. But I like the potential of having a front-end editing capability for those times when the developer determines that the front-end is a good place to edit some things. Spark will be a good project to keep an eye on.