ryan

Thanks guys, hope you enjoy it. I like the way you are thinking! Sounds like an interesting possibility, but a much bigger project. Though if we were to do something like this in the future, I think it would be a separate Process module managing it's own data rather than creating new pages on every login. My thinking is the user logins are much more dynamic and short-lived and it may be best for the implementation to reflect that with a far simpler data type. There is actually a {datetime} tag that you can use in it. It's not documented with the module because the date/time is already a component of any email, and the log already records date/time whether you specify it or not. So the only place it might be useful is in the ping URL... though it's probably better for the ping URL to get it's time from the server rather than the request. But I didn't realize all this until after I'd added the {datetime}, so it should be there if you want it.

I would suggest changing that to: if($input->post->userid && isset($_FILES['imageUpload']['name'])) { But some concerns about your $userid variable (further down). This may not be specified enough. I'd suggest getting the $user first, and making the image_name be based on the user ID (perhaps with the time() component too, if you want it). Just a note here, but you want to be really certain that /site/tmpfiles/profiles/ is a non-web-accessible directory. Further in your code, you were adding it to PW with an HTTP URL, making me think it is web accessible. It's better to use PHP's move_uploaded_file() rather than copy, i.e. $copied = move_uploaded_file($_FILES['imageUpload']['tmp_name'], $newname); There is no authentication here, so any user can substitute another user's info in the POST vars... so the method you are using is not safe. But we'll get to that later. Lets assume for the moment that it was okay to include this in your POST vars (which it's not, but...) you would want to sanitize it differently. If that user ID is the user's ID number (i.e. integer), then you'd do this: $userid = (int) $input->post->userid; If it's the user's NAME (string) then do this: $userid = $sanitizer->pageName($input->post->userid); Also, after you get the $user, make sure that the user exists before adding stuff to it, like this: if(!$user->id) die("Invalid user"); Back to the security issue here. Since you are getting the current user from a POST var, it will be possible for any user to substitute another user's name or ID and change their photo. So I would suggest that you avoid using user ID's at all. You would only want to operate on a user that's already logged in. Or, if that's not an option, then you'd want them to provide their login and password as the user id rather than something else. If you are dealing with a user that's already logged in, you can do this: $user = wire('user'); No need to send that info in POST vars when it's already safely stored in the session. But if your situation is one where the user isn't going to be already logged in, then you'll want your front end form to have login and password inputs, and then get the user that way: <?php $u = $session->login($input->post->username, $input->post->pass); if($u->id) { // they can upload a photo } Before adding the image to your site, I would suggest making a resized copy of it just so that you are dealing with a real image and not something with anything fishy going on in the image format: <?php $filename = "../site/tmpfiles/profiles/$image_name"; try { // if image does not contain valid image data, the following will throw an exception $image = new ImageSizer($filename); // set some boundaries on the size of the image you are willing to work with $w = $image->getWidth(); $h = $image->getHeight(); if($w < 20 || $h < 20 || $w > 3000 || $h > 3000) throw new WireException("Image is out of bounds"); // overwrite old image with new resized version $image->resize($width - 10); // now add to the PW field $u->profilephoto->add($filename); // remove the original unlink($filename); } catch(Exception $e) { unlink($filename); echo "Error:" . $e->getMessage(); } Note that there's no need to specify the URL like this: That makes me think the filename is web accessible–make sure the uploaded files aren't web accessible until after you are certain all is good. When you are adding to PW, you can just specify the local filename rather than the URL (like in my example above). Don't bother with DOCUMENT_ROOT. Just use the same $filename as earlier. If you must have document_root, then use the one from PW instead: $config->paths->root

Provides ability to send an email, ping a URL or save a log entry when a login occurs to ProcessWire. Works with all logins. So if you've made your own login form on the front end of your site, this will still work with it. Download at: https://github.com/ryancramerdesign/LoginNotifier After you click the install button in Admin > Modules, you will get a configuration screen that looks like the following (attached).

I think this is more likely to be a component of the 2.3 version with form builder. However, I don't think you need to wait for that. I would say to build something custom for your need, because this isn't particularly hard to do. When you are dealing with image uploads, you'll want the original uploaded image to be placed in a non-web accessible quarantine location. Then after confirming that it is indeed an image (by checking the extension and using php's get_image_size() to confirm it's valid) then you'll want to use ProcessWire to create a resized copy of it (using the ImageSizer class in /wire/core/). To the best of my knowledge, the resized copy is safe to be web accessible (i.e. okay to add to a page). Once you've done that, delete the original one that they uploaded. At this point, the main concerns would be copyrights (who owns the imagery) and content (inappropriate imagery, if applicable to your case).

Great update Soma!

From a PHP code side I think it looks fine. If you reduce it to just the logic (taking out all the needs of the markup), you've got this, which is pretty straightforward: <?php $content = "<pre>"; foreach($morePoints as $aPoint) { $content .= "\n" . $aPoint->title; foreach($aPoint->children as $subPoint) { $content .= "\n\t" . $subPoint->title; } } This method does become messy if you once you get to a lot of nested levels, or an unknown number of levels. At that time, it's better to take a different approach (recursive function being the option I usually take).

If you aren't running the latest 2.1, you can also do this: <?php $role = $roles->get('role_name'); $user->roles->add($role); Also, to make your code more readable and easier to type, I would suggest localizing the API vars you are using, like this: <?php $input = wire('input'); $sanitizer = wire('sanitizer'); That way you can use them like you would in a template.

Good catch, thanks Pete–fixed.

Great–thanks for the followup and glad you got it working. The main thing will be to watch out for the possibility of having a page with the same name as a user when it's not intended. Of course, if you are limiting this capability to just one parent then that will be less likely.

Looks like I was missing an attribute. Thanks for finding – This is fixed in the latest commit. I agree on the needs for an option to have horizontal image display, at least when using thumbnails. We'll get an option for this soon, and I don't think it'll be too difficult to add.

Your user should just be named "test", without the preceding "user-". I only recommended having "user-" in the page name just for additional clarity and specificity in the page name, but it isn't actually necessary. Also, we are bypassing PW's permissions for this, so don't give them page-edit permission in PW. There's no reason to. And doing so would defeat the purpose of building your front-end forms.

Very nice Soma. I really like a lot of what you are doing with this theme. And you beat me to those pulldowns–well done! I like how they work. Great job with this theme. Only details that came up as questions during testing (and these are really minor): In the PageList, the children counts are resting on a lower baseline than everything else. I also had a little trouble with asmSelect fields (like Page references) with the colors being the same as the container. Like I said, pretty minor. The diamond icon you have in the PageList presents some interesting possibilities, and it got me thinking. At first I thought it was a replacement for the 'move' link or something to indicate a page status. While it's only decorative now, it seems like down the road maybe there is possibility (whether in this theme or another) of having a preceding icon that is functional, whether to indicate the page's status, template, or something like that. Indicating the page's template with an icon (configured per template) was Adam's idea months ago, and I've always thought it was a good one. Though probably something we need to add to the core to make it work.

I don't think that any of these would be actual limitations, it would just determine what approach you take. But if the subject is still "simple poll", then it's hard to get simpler than pages. You'd have a /tools/polls/ section or something, and then a page reference field would let you select what polls you want to show on any given page. Though I understand your desire to build this as a Fieldtype, so if you want to go that route lets keep talking about approach and we can figure out a good one.

You can use limit. As long as specify a limit greater than 1, PW will still count the pages even if it doesn't load them. When you call getTotal() it tells you the total number of matches as if there were no limit. It has to do this for pagination, but it's a trick that's handy to know about even when you don't need pagination.

The problem appears to be a result of characters in your $titolo field. You mentioned you are using $sanitizer, but didn't mention if you are using $sanitizer->selectorValue() before bundling the value into your selector. You would want to do this in addition to any other $sanitizer/sanitization you are already doing. This is because selector values need to be sanitized so that the values in them don't get confused as other components of a selector. So make sure that you are doing this: <?php $titolo = $sanitizer->selectorValue($titolo); $find=wire('pages')->get(1485)->find("template=libro,title%=$titolo"); If that doesn't work, try echoing the value of $titolo before calling find() so that you can see which one is causing the problem. From what I can tell, it starts with "senza censure". I am thinking that you can fix this just with $sanitizer->selectorValue(), but if not then paste in the full value here that is causing the problem and we can analyze it further.

Glad you found a solution to this. You are right that the functions we are using in PHP require full dates, so one can't specify zeros for a given part (except time, if you are using that). If you only need to support a year, I would just use an integer field rather than a date field. If you only need to support a month and year, then something I've done in the past is to just ask the client to specify "1" for the day, and then we only use the month/year component for output on the site. This has worked well for me at least.

You mentioned that you didn't include the /site/config.php from your old installation in your new installation. Your logins won't work if you do this because /site/config.php includes a line at the bottom that looks like this: $config->userAuthSalt = '...'; That is the key to your passwords. If someone ever gets access to your database or a copy of a dump file, they shouldn't be able to decrypt the passwords if they don't have that key. Likewise, a PW install won't be able to work with passwords in a system without the original key that created them. So if you installed a fresh copy of PW 2.0, you'll either want to use the old /site/config.php …OR… copy the last line out of the bottom (that looks like the above) and paste it into your new /site/config.php (replacing the one that's already there). These keys are generated uniquely for each site. Btw, I do have a PW20 to PW21 upgrade process if you want to beta test it this week. I did just upgrade the skyscrapers demo site to PW21 and so far so good. Though note that it does not attempt to copy over users, roles or permissions at present… these things are too different between PW20 and PW21. What it does is create a site profile of your old site. Then you install a fresh copy of PW21 and use the profile it created rather than the one that PW comes with.

I think it might be easier for us to help if you can post the code that isn't working. Though if it's my example above that isn't working, let me know. As with everything, we want to first get it working with the simplest possible scenario with code that only accomplishes the task at hand and nothing more. Then once we've got that working, you'll be able to build from it knowing it's got a strong foundation.

That's way too many pages to try and load in memory at once. I'm impressed you were able to load that many. When you start dealing with hundreds or thousands of pages, start using "limit=n" to paginate whether for output or not. How many pages you can load at once depends on how many fields are being auto-joined to it and how much memory you have available to PHP. Here's are two ways to achieve what you want below. This one loads a max of 3 pages. In the first example, we specify "limit=2" because any limit above 1 triggers PW's pagination (making it include the total matches). So we take advantage of that to get the total: $total = $pages->get(1485)->find("template=libro, limit=2")->getTotal(); This next example requires PW 2.1. We use a "has_parent=1485" in the selector, which is a way to tell PW that the matched pages have to have that parent somewhere in their ancestors . That's something that the first example is doing for you since you are already specifying the parent by calling the find() directly from page 1485. $total = $pages->count("has_parent=1485, template=libro");

The issue you described does happen in FF in some cases, due to the image selection and some issue in TinyMCE (out of my hands unfortunately), but I was thinking this was the same thing. Glad to hear it's not.

A good middleground is fluid with minwidth/maxwidth and centered-- good at any res.

I may be one version behind you with chrome. Based on what you are saying, it sounds like they've added real image selection capability in the latest chrome (something that FF had before but not webkit). I'll check if there is a new chrome update on Monday to test with.

I think this would be possible with the way it's setup. Something to plan for the next version.

Foreach your images and strpos the URL for each one in your body field. When it matches, remove the image from the array. You'll be left with the unused ones. I can post a code sample when I'm back at the computer on Monday if you'd like?

I forgot to mention it before, but that last update should have fixed this too. I changed it to just check for access "page-view" permission, and not any other factors. If you don't have that access then the page wouldn't even be selectable, so I don't think that error message will be seen again in regular use.