ryan

Placing your translatable text in __() function calls is the recommended way to go. It's also the way that PHP gettext() works (though it uses _() rather than __()) and is a universal standard. If you want to keep all your translations in a single file, then that's certainly fine. But I think that's ultimately creating more work for yourself as you end up having to refer to translated text via keys rather than the actual text. The only situation where I might use keys are if I need to re-use the same phrase multiple times, across multiple templates… which would save having to translate the same text more than once.

Works great for me–awesome tool Soma! I have added a note about it to our download page: http://processwire.com/download/ It looks like the domain forwarding service I'm using (Namecheap) won't let me add redirects for anything other than www and @. So I can't add a dev download just yet. But I'll plan to add a dev.grab.pw or grab.pw/dev once I move the DNS.

I'm not aware of a way to control the order and agree it does seem somewhat random. I would assume it's got something to do with the order that they were zipped into the file, but not positive.

This is only something you have to consider if going from a PHP version 5.3.x or newer, and migrating it to a site running PHP 5.2.x. You wouldn't run into this issue going from say PHP 5.4.x to 5.3.x. Also keep in mind that PHP 5.2.x was EOL'd more than 2 years ago. Any servers running PHP 5.2.x need to be upgraded very soon, just as a matter of security. ProcessWire 2.3 is the last version to support PHP 5.2, as PW 2.4 will require 5.3.8 or newer.

removeAll() is a method of a PageArray not a Page. So I think your code will need to check what type it's dealing with in order to avoid that error. if($reset) { if($page->$name instanceof PageArray) $page->$name->removeAll(); else $page->$name = null; }

Sounds like you found a good solution there. I just wanted to mention one alternative that I've used before too, just for the sake of discussion. You can add this to your .htaccess file: AddType application/x-httpd-php .cfm That will make files ending with ".cfm" get run by PHP. Then you could create this file: /store_item_detail.cfm require("./index.php"); // bootstrap ProcessWire $itemID = (int) wire('input')->get->item_ID; if($itemID) { $item = wire('pages')->get("template=product-legacy, legacy_item_id=$itemID"); if($item->id) { // now you can either render the page… echo $item->render(); // …or if you prefer, redirect to it: wire('session')->redirect($item->url); } else { echo "Unknown item ID"; } } else { echo "No item ID specified"; } There you have it–ProcessWire powering ColdFusion scripts.

I agree with Wanze. But if you have a need to make the pages completely inaccessible (via access control), you can always remove guest access at the template level and use "include=all" or "check_access=0" when you need to retrieve them. But if "hidden" will accomplish what you are trying to do, I would use that, as it's more in-line with what it was designed for. Also, minor corrections to Wanze's code: // In your template file if (!$user->isSuperuser()) { // Changed from SuperUser to Superuser (case) throw new Wire404Exception(); } // OR if (!$user->hasRole('superuser')) // changed superAdmin to superuser

Chances are there were duplicate rows. Check what column you are assigning to your 'name' field of the page and see if there are any duplicates in your CSV. If the CSV import module comes across the same one, it'll attempt to update the existing one already there rather than add a new one.

I'm not sure why it won't let you change the language for the guest user, but I'll look into it. However, I recommend aligning your guest user with the default language. The default language is specifically meant to be "whatever language is the default when the user hasn't selected one", in the same way that the guest user is mean to be a placeholder for when no user is present. As a result, the guest user and default language should ideally align. The default language can be whatever language you want it to be... there's no requirement that it be English or anything like that.

I understand the convenience, but I don't think having separate core downloads for PW depending on language (or other factors) is sustainable from a version or security standpoint, so would rather avoid that by always having the core download be directly from our GitHub. But having clear additional download links for language pack, docs, etc., to accompany the main download link would be great. Longer term, we'll have an automated download function that can bundle modules and language packages automatically at runtime.

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?