Leaderboard

Whether 777 is a bad idea or not depends on several factors like whether it's a shared host, and if so, how well the accounts are jailed from one another. I think that many shared hosts are pretty well jailed against problems here now, though that didn't used to be the case. So you have to be careful and critical about your web host in this area. If you are on your own server (VPS or dedicated) and your site(s) are the only ones running there, then it's a non issue. The problem with both 777 and 755 is that even if the accounts are jailed at the shell/FTP level, if Apache is running as the same user (like "nobody", as it does on my server) then a PHP script on one account can write a file to another account anywhere that the other account has an Apache-writable directory. 755 doesn't really help you here (I don't think) because so long as Apache can write to it, the problem is the same. I don't have enough experience with other shared hosts to say how good protection is for that problem. Even if the problem exists, chances are you won't ever have to deal with the consequences as exploiting it can be rather obscure, but it's always a real risk. Consider another risk with shared hosts-- readable files aren't any safer. Another account could create a PHP script that reads a file containing your DB connection info, then connect to the DB and have full read/write access to your database. I think it's best to use a VPS, dedicated or something like it so that you have a completely separate OS instance from any other accounts, and that ensures you can have an Apache readable/writable directory without worrying about other accounts taking advantage of it. Another route is using a server that runs Apache as a CGI or phpsuexec so that all scripts execute as you rather than Apache. In such a case, you would remove read and write access from everyone except yourself, providing a little more security in a shared hosting environment. But shared hosting is not worth the hassle and cost savings in my opinion.

Sounds strange. I'd start by checking that ownership of and (write) access to /site/assets/ (and especially /site/assets/sessions/) are defined correctly; naturally these shouldn't just change overnight, but it's still possible that there's something strange going on at the server. Setting chmod of /site/assets/sessions/ to 777 should confirm whether this is the cause - though I definitely wouldn't suggest leaving it like that for any longer than absolutely necessary.. Also: is PW writing anything into it's own error log (/site/assets/errors.txt)?

You can also do this in newer versions of PW: $newpage->template = 'upload'; $newpage->parent = '/uploader-test/'; I suggest sanitizing the title, and excluding the name (since PW will autogen it from the title). So the above code would be replaced with this: $newpage->title = $sanitizer->text($input->post->title); Here is the current PW implementation for uploaded files. Perhaps there is a way we can populate this to $input->files, but currently I think it's best to be more specific when it comes to file uploads since there are added dangers and overhead. The WireUpload class does make things simpler and more secure. It also provides options for handling known quantities, filename sanitization, overwriting vs. making unique filenames, processing ZIP files, handling ajax uploads, etc. The full class is in /wire/core/WireUpload.php

Here's my very first and not polished version of ru-RU translation. So, now you can enjoy all this cyrillic madness Ryan, I have a question. Is it possible to store cyrillic symbols without this transformstion to Unicode (?), so the json files are editable in any editor? It's not too much needed though. Update: I've just created a GitHub repo ProcessWire Russian Language Pack ru-RU where you can find the latest Russian language pack for PW's backend. Also attached a new version of the pack, but in future I won't be updating it here, so please download it from GitHub. slkwrm-ProcessWire-Russian-Language-Pack-ru-RU.zip

As our studio is getting close to finishing another project, we are facing the challenge to provide our client with easily understandable materials or kind of a manual on how to manage content in PW. As I guess that this happens from time to time to you guys around here, too, I wonder if it would make sense to collaborately work on a kind of manual document explaining key actions to be done for an editor. So there could be an open document or wiki providing texts in different languages and supportive images we all could use to e.g. turn it into a nice PDF or printed handbook (yes, some clients still like paging through paper) where we just have to replace images. I don't think this work has to be done over and over again by each one of us for his own purpose. And I'm sure, all our clients would benefit from something like this. Also it would be a nice plus for everyone thinking about using PW the first time for a client project.

Alan, you don't necessarily need to use PW's MarkupPagerNav module if all you need are next/prev links. Here's how you might do it instead with your own code: $limit = 5; $items = $page->children("limit=$limit"); $prev = $input->pageNum > 1? $input->pageNum-1 : 0; $next = $items->getStart() + $limit < $items->getTotal() ? $input->pageNum+1 : 0; if($prev) echo "<a href='{$page->url}page{$prev}'>Prev</a> "; if($next) echo "<a href='{$page->url}page{$next}'>Next</a> "; If you prefer to use the MarkupPagerNav module instead, then you could always just hide the numbered links with CSS: ul.MarkupPagerNav li { /* hide all the links */ display: none; } ul.MarkupPagerNav li.MarkupPagerNavNext, ul.MarkupPagerNav li.MarkupPagerNavPrevious { /* display just the next/prev items */ display: inline; }

Just to give more explanation behind it, the "a" class is meant to count from the beginning, so "a1" means first item, "a2" means second item, etc., while the "z" class is meant to count from the end so "z1" means last item, "z2" means second to last, etc. It could just as easily be called "from-the-beginning-1" or "from-the-end-1", but just wanted to make sure my extra short class names weren't causing confusion. The purpose of going this route was to keep comparisons to numbers rather than objects. We know that the first item is always going to have a key of 0, and the last item is going to have the key of $page->numChildren-1. So we don't really need to call first() or last(), though there's no harm in it either. The only other real difference here from earlier examples is just that I'm not using the getItemKey() method. It's not necessary to do that because anytime you call foreach() in PHP you have the option of including the $key in the foreach. As a result, this: foreach($page->children as $key => $item) { is the same as this: foreach($page->children as $item) { $key = $item->getItemKey();

Hi onjegolders, You can find several ideas here on how to process/create your own forms:

I think Ryan has a module for this already. Have you tried out FormTemplateProcessor?

Ryan I was just thinking that it would be great if this was carried on in some way. I think the main advantage of having a whole site tutorial is that so many different methods come up that we all face in our projects: How you organise your templates How you go about changing permissions so that the end-user only edits what is needed Field types Navigation I think when it's all part of a project then it's easier to grasp and people will come out the other end of it with a much better idea on how to do their own projects. I know time must be very short and if there's any way I can help out, I'd be delighted. I also must stress that on a general level, the documentation here is outstanding, I just think an all-inclusive project walkthrough would be the icing

Hi Carlos, you probably just hit on the memory size limit in PHP. You could try editing the server's php.ini file (if you can) and increasing the limit. On debian based distros you'd need to edit /etc/php5/apache2/php.ini but on other platforms I don't know where the file is. If the file is not accessible to you, you might need to contact your web hosting provider.

Ryan, check out flourish's handling of sessions for some inspiration too. Though not fully documented at the front-of-site, it allows different session storage mechanisms via the setBackend() static call. I have to add, I haven't used this personally but thought I'd throw this into the ring if you are about to do some research.

This is great news, I didn't know about that. Thanks Ryan. Later I realized that I can use git to keep the code up-to-date (it isn't a revolutionary idea ).

Neil, thanks for posting the JSON solution you used. Regarding PHP versions: not even WordPress will run in PHP prior to 5.2.4. Some big red flags at that web host… run away!

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.