ryan

If that fixes the issue, I'll add a line to our core /index.php that only applies the session.save_path if the session handler is 'files'.

I'm not really sure about this one. What inline styles are on the table? I'd probably prefer not to have any inline styles there. But tables don't always obey the rules. If the content is larger than what the table can contain, I think browsers may not always be consistent in how they handle the situation regardless of what styles are applied.

This option may be coming in the future.

I think that once the HTML5 datepickers across all major browsers reach a level of maturity where they are as good or better than the jQuery UI one, this makes sense. Though how does the HTML5 datepicker support multi-language and various date formats? Currently, we are translating custom date formatting strings between PHP and javascript. Does the HTML5 datepicker support time input too? I guess I have to read up more on the HTML5 date picker, but am wondering if the multi-language aspect especially might present more challenges in HTML5 than javascript.

Pogidude, you are correct in all of that.

For stuff like this, I would be more inclined to use an Apache rewrite rule, just because there would be less overhead and code to make it happen. Something like this might work in your .htaccess (somewhere after the "RewriteEngine On" line): RewriteRule ^(continent[0-9]+)/(land[0-9]+)/(project[0-9]+)/donation/?$ /stuff/donation/$3/$2/$1/ [R=301,L]

Awesome work Horst!

I think it's probably just whatever you find most useful in your situation. But my preference is usually to sanitize on first access, unless I potentially need an unsanitized version to determine how it should be sanitized (which might be the case here). You could sanitize first with pageName (which sanitizes to [-_.a-z0-9], and then use ctype_digit to determine if it's an integer or string: $value = $sanitizer->pageName($input->post->something); if(ctype_digit("$value")) { // it's an integer $value = (int) $value; } else { // it's a string }

Name is a consistent term used throughout ProcessWire and also the term used at the API level, so I'm not sure it's necessary a good idea to change it (or at least it might be confusing). But I'm guessing it could be done by way of a hook after ProcessPageEdit::buildForm: public function hookBuildForm($event) { if($event->object->getPage()->template != 'user') return; $form = $event->return; $field = $form->get('_pw_page_name'); $field->label = 'Username'; } As for "page name in address bar", I don't think that we ever actually use the the name in the address bar for users since there is no /site/templates/user.php by default. So I'm confused on that one.

If you've got a situation where you are having to do something repetitive (like the image selection and placement you've mentioned), then look at breaking it down further. Images manually positioned in copy (via TinyMCE) aren't ideal, and are better for one-off or unique situations. It's better to standardize on dedicating a specific image field (i.e. featured_image) to be a method of automatically connecting an image with a page. There are also situations where you may find it helpful to associate images with page references. For instance, a blog post with categories might have the categories each have an image that gets automatically pulled in and displayed when the blog post is rendered.

If I understand it correctly, it looks alright to me. We've done things like this before, connecting the user name with another page though rather than having a saperate "username" field, we just used the existing page "name" field to connect with the username. So that's the only thing I'd say, is to double check that you really need an extra "username" field, or if you can make use of the built-in name field to do all this.

I'm not sure I understand this case. The error you are getting is what I'd expect if the LanguageSupportPageNames module wasn't installed. But since it is installed, it's a bit of a mystery there. I'll see what I can do in trying to reproduce it. But you do have an alternative to the localUrl() function, and that is to just set the user's language for each iteration of your $languages loop, and then call $page->url: $saved = $user->language; // save user's language foreach($languages as $language) { if(!$page->viewable($language)) continue; $class = "$language" == "$saved" ? " class='active'" : ''; $user->language = $language; echo "<li$class><a href='$page->url'>$language->title</a></li>"; } $user->language = $saved; // restore user's language

If the internal server error is coming from ProcessWire (as opposed to Apache), then you can enable debug mode or check your /site/assets/logs/errors.txt to see what the actual error message is.

There aren't any core security issues that I can find here. But Khan is right that the email address really should be unique, just as a general security principle. Not enforcing unique emails does lead to potential security issues, or at least plenty of ambiguity when writing login/password related stuff. We should spare people from having to think about that in their own API code, and think the solution has to be at the database level with a unique key on the email field. That way if you are writing your own front-end login and/or password reset capability, you don't have to consider the implications of email addresses not being unique. If you have the core "forgot password" module installed, then realize that your account is only as safe as your email (which I think is safe to assume for any such function). That means that you should only put in email address you have access to, and if you ever lose that email, then make sure you update your account with your new email address. But of course, that would be a problem whether in ProcessWire or anywhere else. But there is a reason why the "forgot password" capability is not installed by default, and that's because such features always reduce security, even if they are written in a secure manner. So as always, leave the forgot-password capability uninstalled unless you absolutely need it (whether in PW or anywhere else). Yes, you'd basically be giving the other person access to your account. Or at least the ability to reset your password. But it doesn't really matter if that person has an account or not, so long as the email has a recipient. But this is the nature of the beast, whether in ProcessWire or elsewhere. I suppose making email addresses unique doesn't really matter all that much in this case. But I still agree on the value of having emails be unique. It just makes for a more bulletproof/less ambiguous user system.

Not sure I get it, but I've been working hard all day and my mental energy is low. Nico it sounds like you get it? I went ahead and tried to reproduce the scenario, but can't seem to break anything here. Maybe I'm missing something? The email address is not an identifier for an account. Meaning, one can't login with an email address, nor does PW use the email as any kind of unique identity. If you think there is a security issue that can be reproduced, can you PM me the steps to reproduce?

I agree on these. I have actually tried to implement an upload in the image dialog before. But it's a tricky thing, in that the destination field of the image needs to be configurable, and the image needs to go in the parent window too. So I've left that as a "nice to have" for the future, as I'm not really sure how to implement it as present.

I guess I'm not sure exactly what post you are referring to? But I think the guys that wrote before me nailed it pretty well. I think not everyone has the same needs when it comes to images, and not trying to suggest that everyone should think the same thing here. I'm ultimately interested in the most flexible solution that can work anywhere, and that's what we've adopted. That doesn't mean it's the perfect solution for every case. I'm not sure I understand. Is there any way to bypass the process of uploading photos and typing/pasting text in the editor, in any scenario? The only thing I can think of that would be simpler is if you could literally copy the whole chunk, photos and text at once out of Word, and paste it in there. But I don't think this is what you are talking about? It's good to have large source images. But if they are too large, you might want to set max dimensions in the image field. Of course, you'll also want to enable the thumbnail option for the image previews that appear in the editor. This is an important one… you don't want to have giant images consuming the editor space. I'm not sure I understand the problems you are running into here. Because currently it seems like the usual way of inserting images is quite good here no? Upload image(s) … when you find a place in text where you want to insert image, click image icon … select image … resize and align as needed … click insert button. It also doesn't seem like this process would be any different regardless of whether an image manager is installed or not?

// assuming your images field is named "images": $pagesWithImages = $pages->find("images.count>0"); // now that you have all pages with images, you can put them all in 1 array if you want $allImages = array(); foreach($pagesWithImages as $p) { foreach($p->images as $image) $allImages[] = $image; }

I think that you could do this: if(count($image->getHooks('getThumb'))) { $url = $image->getThumb('thumbnail'); } else { $url = $image->url(); } another way: try { $url = $image->getThumb('thumbnail'); } catch(Exception $e) { $url = $image->url(); }

Yes it should. Though you'll want to remove the DB connection and userAuthSalt information at the bottom of the config.php before bundling it in your profile.

Awesome Kongondo! I haven't gone through the whole thing yet, but am printing out so I can read in more detail. But it's clear you've put a lot of great work and thinking into this, Thanks! I can't wait to read it in full.

I'm not really sure why it might not be working in your case, but it definitely doesn't sound right. It reminds me a bit of what one sees if they are trying to run ProcessWire without an htaccess file. What version of ProcessWire? Also, double check that those links have a trailing slash in them. The one you mentioned did not have a trailing slash, and I suspect that this module would require them.

Pete, you can store arrays in a module config: $data = array( 'options' => array( '/path/to/page/', '/path/to/another/page/' ) ); $modules->saveModuleConfigData('MyModuleName', $data); Of course 'options' could be an associative array too if you wanted it.

Nico made this and I think that he was possibly going to prepare a template that could be used for other languages (Nico?). I think it's a great template and would be good to re-use. But it ultimately comes down to what the needs are for the individual site. I can setup hosting to point to the processwire.com server or an outside IP. If you'd like it on our server here, let me know and I'll setup an account. If you'd like it pointed to the outside IP, just let us know when something is ready at a temporary URL and then we can get the DNS setup.

I'd love to get involved with a ProcessWire book at some point. Last I heard, Matthew and Joss (?) and maybe Pete (?) were working on a book or books. But I'm not sure what the status of those is.