ryan

Thanks guys, it was a great trip. Thanks to everyone for keeping an eye on things here. Finally back on land and just need to get back home and unpacked. There was so much to do onboard, I didn't end up even turning on the computer the whole time. Though I checked my email a couple times from the internet cafe just to keep an eye out for any emergencies. It may take me a couple days to get all caught up with messages here, but I'm going to start chipping away at them now and should be back to a regular day in my office tomorrow.

I'm leaving tomorrow for vacation and going to be offline all next week. I've got friends staying at my place to keep the business running and cats happy, but during that time you may not see any posts, tweets or commits from me. Just wanted to explain ahead of time so nobody thinks I've disappeared. Though if internet access presents itself, then this will be the first place I'll check in, but just wanted to provide adequate notice if that didn't happen. I'm taking the laptop with me and hope to get some PW updates done on the road as well. If you don't mind, please keep an eye on this place while I'm gone. If any new users drop by here, make them feel at home. Hope you all have a great week next week. Thanks, Ryan

FieldtypeRepeater was added after 2.2 was initially released. The current version number should read 2.2.0.1. It is true that all you need to do is replace your /wire/ directory with the new one. But rename or backup up the old one, and backup your DB to be safe. It is also recommended that you replace your /index.php and /.htaccess files with the new ones, though I don't think that will be necessary for going from 2.2.0 to 2.2.0.1. After you replace your /wire/ dir, the first pageview will produce an error. Just hit reload in your browser and then it should be back.

Thanks for posting the full thing. But I'm confused because I can't relate it back to the original post. There's no $event argument in the hook. To me this looks like something that would be suitable as a LazyCron hook? At least, if it's not using anything about the current $page from Page::render, then you may not want to saddle it with this on every request. What's the exact error message you are getting? And is it the $currPage->save(); line that is throwing it? You might want to enable debug mode to see the debug trace to be sure.

I found that codemagic wouldn't work anywhere other than in TinyMCE's main plugins dir because it has hard references to some TinyMCE file in the parent dir. I know that can be fixed by making a copy of that file it is referencing, but that's not desirable and perhaps could cause bugs elsewhere. I've left codemagic in the TinyMCE code for now, but just not including it in the default TinyMCE config. So if someone wants to add it, they can do so by adding codemagic to their plugins list and and not have to worry about it being overwritten on upgrades. Still, only being able to use it with 3 languages is a shame. I can't believe TinyMCE has no fallback for language support other than a JS error. The other thing is that codemagic's list of words to translate is pretty short. It wouldn't be hard to add all the translations that TinyMCE supports. Google Translate told me she would help me out with this if I wanted.

The only dir that needs to be writable to ProcessWire is /site/assets/. If you migrate files to a live server, and PW can't write to that dir, it probably won't let you login because it can't create a session. Here's the chmod command (executed from site root) that would fix that: chmod -R og+rw ./site/assets That means make it readable and writable to "other" and "group" which includes everyone, so certainly going to include Apache. Depending on your hosting environment, you may not want that quite as open-ended, in which case you'd need to use different permissions... probably giving permission just to apache via its group. Something like this, though going to depend what group apache uses: chgrp -R apache ./site/assets chmod -R g+rw ./site/assets Many hosts have Apache running as you, in which case none of this matters so long as you yourself have read/write permission.

Forgot to add, of() is the same thing as setOutputFormatting(). I just added that as an alias recently because it's easier to type.

I had a Page::render hook handy to test with, but can't duplicate this one. The code you originally posted wouldn't work because it was calling setOutputFormatting on a non-object (before you had $page), but you indicated that the order was corrected, so sounds like that's not it. Here is my working version if it helps: public function example2($event) { $page = $event->object; // make sure you exit if it's not the $page you want if($page->template != 'basic-page') return; $page->of(false); $page->summary .= " test"; $page->save(); $page->of(true); } Please paste in the full code to your function again if it still won't work and I can copy/paste into mine.

Good questions. I'm not sure I can add anything to this since I've not had to deal with this particular issue before (I only know English, unfortunately). But thinking that anything that relates back to a function/property/class name that you would use in PW should probably use the same term, or repeat it in parenthesis or something? Just to avoid API confusion.

Thanks for confirming. I will try this on the road next week. I just submitted a GitHub issue report so I don't forget.

vmcosta is right about this, as this was fixed recently. Though just in case there's something different about this scenario, please double check once you've got the latest version and let us know. Thanks, Ryan

With scp you'll want to specify the "-p" option to retain permissions in the transfer, i.e. scp -r -p ./site/templates/* user@domain.com:www/site/templates/

That doesn't work because $input->post is an object, not an array. If you wanted to get a PHP array, you'd call $input->post->getArray(); instead. However, I would be very careful about blindly storing everything from GET/POST into a $session. Keep in mind that data in a session is stored on your server, not on the client side like a cookie. You want to know exactly what you are storing in $session and make sure that its clean. Storing everything from POST into $session would be a security hole in any application. How the hole could be exploited would come down to what you are doing with the stored data... you would certainly have to treat it as tainted data any time you retrieved it, which is different from how we usually think of session data. Another way it could be exploited is by someone repeatedly submitting huge POSTs and filling up your hard drive with session data, or DDOSing with giant posted arrays. So if you go the route of storing unknown POST data, you can't really validate it. But I would at least sanitize it by limiting the quantity of elements you store, limiting the length (bytes) and depth of those elements, make all the array elements strings, and running them through htmlentities() before storing in the session.

I don't really know the answer to this question, but think this is going to depend on what tool you are using to upload, or possibly something with the host. Are you using FTP or something else like scp or rsync?

Soma, did some more testing here and found that the $user->language; reference in LanguageSupportFields could possibly be circular when $user->outputFormatting was ON, and it looks like that's what was causing the strange behavior and notices. This is fixed in the latest commit. Thanks for finding it.

What Soma posted looks right to me. This is similar to what PW's Inputfield does. Though I'm not sure that the double save is necessary (though not hurting anything either). I was just able to duplicate it! Though only when echoing a user field like $user->email. I'm still not getting any notices as a result of just a $user->of(true); call. But I think getting the notices from the echo is enough here for me to fix.

Welcome to the forums Sylvain! It looks to me like you are storing the entire $input->post or $input->get as a session variable (though let me know if I'm wrong?). // avoid doing this $session->something = $input->post; Instead, you just want to store specific variables from post/get after validating/sanitizing them. For instance, here's how you might store a variable called num_people, submitted via POST in a session: $session->num_people = (int) $input->post->num_people; Then at any other request during that session, you should be able to retrieve the value like this: echo "Number of people: " . $session->num_people;

Sounds good, I will update.

Just to make sure I understand correctly. Do you think it's best to replace this (in LanguageSupport.module): setlocale(LC_ALL, $this->_('C')); with this? $locale = $this->_('none'); if($locale != 'none') setlocale(LC_ALL, $locale); The above would only call setlocale() if the language defined a locale in the translations.

I'm not sure if the logout notifier is worth doing because a large number (or most?) logouts are due to session expiration. For example, user logged in, made some edits, then left. In such a case, the user never performs a logout. But their session expires later that day when PHP's garbage collector comes along and cleans out old session files. Unless the user continues using the site till the end of time, it's safe to assume that every active login will end at some point (whether by their action or by PHP's). But if you still want to track actual logouts, you can. PW provides a hook that you can use: $session->logout. In the LoginNotifier module, I think that you could duplicate the login hook in that module, and copy it verbatim to make the logout hook (replacing 'login' with 'logout), and I believe it should perform what you want. Just keep in mind that you won't see near as many logouts as logins, since not everyone clicks the logout link when they are done.

I wanted to add a note about exceptions on the front end. If you want to abort a request, throw a WireException: throw new WireException('your error message'); That message will automatically go into the errors.txt log and email the site administrator. If the site is in debug mode or you are a superuser, it will report the error message to you as well. If not debug mode and not superuser, the user will get a generic "an error occurred, administrator has been notified" message. Another exception you can throw is the 404. This will make PW display the 404 page (from your site tree) and send the proper 404 headers to the browser. PW doesn't interpret this as an error that needs to be logged or emailed. throw new Wire404Exception('page not found'); This is the exception you might want to throw if you get an unrecognized URL segment, for instance.

Marc, when you are developing a site it's good to turn debug mode on. This will ensure that errors are sent to the screen, exceptions reported, etc. This can be found in /site/config.php. By default, it is false. You'll want to change it to true: $config->debug = true; Obviously you don't want this enabled for production sites, so remember to change it back to false for live/production sites. I don't see any problem with using var_dump, var_export, print_r, etc. so long as you are directing that output to where you can see it. Also avoid running these functions on PW objects as you may get into an infinite loop. Sometimes it can be difficult to track the output of these functions because PW performs a redirect after most POSTs. But if you use PW's built-in reporting functions, they will get queued between requests until they are output. Here are the relevant functions bellow. They will produce the messages that you see at the top of your screen in PW admin: $this->message("status message"); $this->message("status message that only appears in debug mode", Notice::debug); $this->error("error message"); $this->error("error message that only appears in debug mode", Notice::debug); If you are outside of a Wire derived object, you can call upon any API var to handle the notice for you. For example: wire('session')->message('status message'); wire('pages')->error('error message'); Note that these reporting functions above are for the admin (and related modules), and they don't do anything on the front-end of your site. How you choose to debug or report errors on the front-end is at your discretion. Personally, I keep debug mode on in development, and this puts PHP into E_ALL | E_STRICT error reporting mode... it reports everything possible. If I need to examine the value of something on the front-end, I'll do it the old fashioned way with just PHP. Though others may prefer to go further with their debugging tools. If you want to keep your own error log, here's how (anywhere in PW): $log = new FileLog($config->paths->logs . 'my-log.txt'); $log->save('whatever message you want'); You can direct it to store logs wherever you want, but I suggest using the PW logs dir as shown in the example above. This will make the log appear in /site/assets/logs/, and this directory is not web accessible for security.

@Soma are you running the latest? I'm not getting the notices here, doing the same thing. But if the notices are the same as the one you mentioned earlier, you don't need to worry as the condition is expected (though the notice isn't). I can add an extra check to prevent notices there, but want to make sure we're running the same version first. @Renobird there actually isn't such thing as a single image field to ProcessWire beyond that output formatting setting. All image fields are multi-image fields behind the scenes. If you enter "1" for max files, and output formatting is ON, then PW takes the first image from it and makes that the value of your $page->image field. So this does a good job of hiding the fact that all image fields are multi-image fields, because anyone that uses them in their regular site development never knows the difference. Likewise, PW's image inputs are monitoring that max files setting and limiting the input to just 1 image. In your case, you are trying to modify the field value, so you have to do the same thing that PW's inputs are doing. My suggestion would be to just set your "max files" setting to 0 so that you are developing with a multi image field. The maxfiles=1 is primarily for output convenience and in your case it's less convenient, so just stick to a multi image field and maybe go back later and adjust it back if you'd like to. This is the same approach PW takes, as any code administratively dealing with images/files is not considering that max files setting until just before output or input.

Bill, that actually makes sense. I've done a var_dump on pages before, and it basically becomes an infinite loop (or something close to it).

Where are you calling $user->of(true);? Or is the call to $page->images; causing the notice? I'm not sure what line 126 in LanguageSupportFields.module is referring to because line 126 is a function() statement, so not the one that's generating the error. Some updates were put in recently to the language modules, so you might not have these yet. Either way, the notice is not a concern, as these functions can get called before fields are loaded. Though once we find out where it actually is I can add in an extra check to avoid the notice getting thrown. I did try to duplicate the setup here, but am not getting the notice so it could be version related. Btw, taking a closer look, output formatting is pretty much always off for users, unless you turn it on. So to get the $user->image behaving as a single image, you'd just have to turn the output formatting on for the $user. I think that's all there is to it.