ryan

I don't think sharing one database for multiple pieces of software is a good idea. Lots of concerns there whether PW is part of it or not. A vulnerability in one piece of software suddenly becomes a vulnerability in all. Table prefixes have been intentionally left out of PW, and I'm of the opinion that this is something other software should phase out as well (especially WordPress). I'm guessing this is from a legacy hosting platform or a free web hosting account, and so would say it doesn't meet PW's minimum requirements in that regard. I understand the hosting part is out of your hands, but would probably suggest kindly encouraging your friend to get a $3/month web hosting account from HostGator or something, so they can have more than one database. Though it surprises me even a free host would still be enforcing that limitation as it's a magnet for security problems and tech support.

Another approach you could use would be to use PW's WireUpload class: $ul = new WireUpload($field_name); The rest here:

<p>Pete this should be enabled as a configuration option by default in your /site/config.php. Though I don't know why the server in your case is using different permissions. But take a look at these lines in /site/config.php just in case: </p> <p> </p> <p> </p> <div><span> </span> <div><span>/** </span></div> <div><span> * chmodDir: octal string permissions assigned to directories created by ProcessWire</span></div> <div><span> *</span></div> <div><span> */</span></div> <div><span>$config->chmodDir = "0777";</span></div> <div> </div> <div><span>/**</span></div> <div><span> * chmodFile: octal string permissions assigned to files created by ProcessWire</span></div> <div><span> *</span></div> <div><span> */</span></div> <div><span>$config->chmodFile = "0666";</span></div> <span> </span></div> <div> </div>

This error can be ignored as it's just a PHP strict notice, but I've gone ahead and updated the functions in those modules so you won't get notices when in strict/debug mode. I recently added a flags param to the error() and message() functions, and hadn't updated the 3rd party modules that implement that function. Thanks for letting me know -- now fixed.

I still plan to go the tags route, at least when it comes to version numbers like 2.2.1, 2.2.2, etc. Just haven't gotten to it yet, but will soon. I don't think this is what you are looking for, but also wanted to mention how you can access the version number from the API. $config->version; holds the version number in a string, like '2.2.0'. You can also access the individual components as integers from ProcessWire::versionMajor; ProcessWire::versionMinor; and ProcessWire::versionRevision;

I'm going to be adding an option to store sessions in the DB soon too, so this will be another alternative option for those that want it.

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.