ryan

These Russian characters have been added in the latest commit.

Nice work 12345J You've gone from something very simple to something that I don't understand–a good thing when it comes to obfuscation. And it looks good! If you don't mind me asking, how does this work? I'm learning something new here, as I'd not seen create_function() before, but I'm intrigued by this. I'm sure I could figure it out by going through the code in more detail, but figure it might be good to include a brief summary of what it's doing in your module readme file for when we add to the directory (if you'd like me to). Also, how are you including the JS? I don't see any calls to include the JS. I'm guessing that one would include it manually from their template, but want to confirm? That's certainly a fine way to go. But in case you are interested, here are a couple ways to make it get included automatically: Add it to $config->scripts, like this: <?php $class = $this->className; $config->scripts->add($config->urls->$class . "$class.js"); When building sites, I recommend that developers include scripts (and styles) in this $config item in your own header include (or main template) so that modules can add scripts. So this is what developers would add to their sites, rather than individual links to specific scripts or stylesheets: <?php foreach($config->styles as $url) echo "<link rel='stylesheet' type='text/css' href='$url' />"; foreach($config->scripts as $url) echo "<script type='text/javascript' src='$url'></script>"; This is the method I use in my own sites, and this is also the method the PW admin uses. I think it's pretty handy because if I need a specific script or css file for a given template, I can just add it to those $config vars before including my header. For example, lets say I had a rotating feature on my homepage and wanted to include the jQuery cycle plugin to do it. Here's what the template might look like: /site/templates/home.php <?php $config->scripts->add($config->urls->templates . "scripts/jquery.cycle.lite.js"); $config->styles->add($config->urls->templates . "styles/home.css"); include("./head.inc"); // output homepage specific content and markup include("./foot.inc"); As handy as that is, it's ultimately up to the developer to decide whether they take that approach in their own templates. But I'm thinking we'll encourage people to do something like the above more and more in the future. That would make it easier for module developers to have a standard way of adding stylesheets and JS to site templates. Another method you can use that is not quite as pretty, but doesn't require the developer to do anything, is to add it to just do another string replace in your obfuscate() function. Add your script right before the closing </head> or </body> tag. i.e. <?php $class = $this->className; $url = $config->urls->$class . "$class.js"; $event->return = str_ireplace("</head>", "<script src='$url'></script>\n</head>", $event->return); This is probably the best way to go for simplest possible installation of a script into a unknown HTML output.

That move in the page tree refers to moving or sorting (they are synonyms in this context). Since your page can't be moved to another parent, it can only be moved within the same parent (aka sorted).

Use your title field for the term, and another field for the definition. For the parent of all these terms, set the default sort to be by 'title' on it's children tab. Then you'd code it something like this (below). I'll use a <dl> rather than a <ul> since a <dl> would be more semantically correct here. <?php function listDefinitions(PageArray $children) { $out = ''; $lastLetter = ''; foreach($children as $p) { $letter = strtoupper(substr($p->title, 0, 1)); if($letter != $lastLetter) { if($out) $out .= "</dl>"; $out .= "<h3>$letter</h3><dl>"; $lastLetter = $letter; } $out .= "<dt>{$p->title}</dt><dd>{$p->definition}</dd>"; } if($out) $out .= "</dl>"; return $out; } echo listDefinitions($page->children);

Good find Soma! It was a typo in the code, so the noSettings and noTrash were connected in a manner they shouldn't have been. Just fixed in the latest commit. Thanks!

Thanks guys, I could definitely use help testing. I didn't realize there were so many people wanting to do the upgrade, so I will try to get this finished sooner.

What's missing here is to move your file from $filetemp to $path + $filename. Once you've confirmed that the $filename is consistent with the format and extension you are expecting, and the size is consistent with a size you are willing to email, then you'll want to use PHP's move_uploaded_file($filetemp, $path . $filename) to the destination. If this is coming from a non-administrative upload form, you'll want your destination to be non web accessible. That means a directory off your /home/ or a directory blocked by apache. In a PW installation, everything is blocked from /site/assets/cache/, so that is a possibility. Here's how you might do it: <?php if(isset($_POST['submit']) && !empty($_FILES['file']['size'])) { $filename = $_FILES["file"]["name"]; $filetype = $_FILES["file"]["type"]; $filesize = $_FILES["file"]["size"]; $filetemp = $_FILES["file"]["tmp_name"]; if($filesize < 10) throw new Exception("File too small"); if($filesize > 1000000) throw new Exception("File too big"); $ext = strtolower(pathinfo($filename, PATHINFO_EXTENSION)); if(!in_array($ext, array('jpg', 'gif', 'png'))) throw new Exception("Invalid file type"); $destination = $config->paths->cache . $user->name . '.' . $ext; if(!move_uploaded_file($filetemp, $destination)) throw new Exception("Unable to move uploaded file"); // fopen $destination and encode for your email // and remember to delete the file when done: unlink($destination); // then send your email } Written in the browser, so may need tweaks. Also, the messages posted this week from this thread may be helpful too: http://processwire.com/talk/index.php/topic,83.0.html

We could certainly add this and seems like a good idea. I'm not an expert with TinyMCE other than being familiar with some parts of it that I had to in order to make it work with PW. I do have plans to do more with it in the future, but it's admittedly not on the short term roadmap yet. If you want to take the lead on this I'll be glad to collaborate with you on it and we can get anything into the core that needs to be there to make it happen.

Ah I see what you mean. I think it's a good idea, but one I should probably leave for another theme developer. I'm admittedly not a fan of the plus/minus for opening/closing things just because I don't have the best eyes and those things are always too darn small for me to use effectively. But I do understand why others may like the ability to open/close children as being something separate from open/close page actions. And I would guess that it won't be long before we see a theme that does that. With regard to borders in the PageList: many of the sites I work on have thousands of pages and so the default theme is kind of designed around my own needs to be as minimal as possible when it comes to displaying page information. Extra borders and such are nice separators on small sites, but get in the way (for me at least) as the scale of pages increases. But perhaps I can make a variation of the default admin theme at some point in the future that incorporates things that others may prefer.

First post and you are uploading a module! Nice. A couple things I noted and wanted to ask about: Correct me if I'm wrong, but I think this would break mailto links like this: <a href='mailto:mike@yep.com'>email me</a> Would become this? <a href='mailto:mike<span style="display:none;">1234567</span>@yep.com'>email me</a> It looks like it would replace all instances of the "@" character, whether they were email addresses or not? So that this: Becomes this (though not that big of a deal here): So if you use this obfuscation method, I'm thinking it might be better to use a regular expression so that you know you are matching email addresses, i.e. <?php if(strpos($event->return, '@')) { $event->return = preg_replace('/\b([^\s\r\n]+)@([-.a-z0-9]{2,}\.[a-z]{2,4})\b/i', '$1' . $rand . '$2', $event->return); } Written in the browser and not tested, but I think that would work (let me know if it doesn't, as it sometimes takes me a couple tries making these regexps). Granted, preg_replaces aren't nearly as fast as str_replaces, but they are much more accurate with something like this. And technically, this may be even better as a Textformatter module rather than a page render module, but I can see value in either. But we're still left with the problem of mailto links. We could easily make the regexp exclude emails that start with "mailto:", but then it would hardly be obfuscated. My experience has been that the only way to get effective obfuscation with something like this is a combined PHP and JS based solution that has the email encrypted in the markup, and then some JS comes in and decrypts it. something relatively simple like a rot13 encryption/decryption, or even just reversing all the characters in the email address is likely to be adequate to keep the bots out. Ultimately it's not the most accessible solution (requiring javascript) but a worthwhile tradeoff in many instances.

There is not an official doc on this yet. But I have just upgraded the skyscrapers demo site from PW 2.0 to 2.1 last week, so I now have a way to go about it. Note though that it doesn't touch your existing 2.0 install. Instead, you basically download a new copy of PW 2.1 (on another site or another directory), then copy your /site/ directory from 2.0 into your 2.1 dir. Then you run the installer. It takes care of the rest. Once you are certain your new 2.1 install is all good, then you can move or delete your 2.0 install. In order to make it as simple as possible, I created a module that does much of the work for you. However, I want to test it on a couple more sites before making it public. But if you would be interested in beta testing it, let me know? Lastly, I want to mention that the user/access system in 2.1 is quite different than 2.0. Most people don't have a lot going on with users since 2.0 wasn't particularly strong in this area. As a result, that is one thing that does not translate from 2.0 to 2.1. So if you have a lot of users or access settings, I'll want to help you individually with that. Thanks, Ryan

There is no guest to uncheck in 2.1 on the page itself (it's in the template settings), so that would be the way to do it with 2.0. With 2.1, you'd just want to keep it unpublished and view it that way. No solution yet for previewing changes to already published pages, but ultimately it won't be too difficult to implement. In fact, draft versions were originally in 2.0 and they'll be coming back. I took them out shortly before releasing 2.0 because: it was one of those things that worked, but I felt was more code behind-the-scenes than the value it provided, so it got the axe. So figured I'd come back to it when I found a simpler way to accomplish it. Now there is a simpler way thanks to the new $pages->clone() function. So in the future when you click "save draft", it'll clone a hidden/unpublished sibling partner page (that you won't see in the PageLIst). When you edit the original, it'll load the partner page instead until you either publish (overwriting the original) or abandon the draft. It won't take much more than a days work, so may try to work it in at some point soon, but most likely it'll come shortly after 2.2.

Thanks Shane, glad you got it working. It sounds like you are using v2.0. If you use 2.1 on a future site, note that all those access role settings are now with the templates rather than the pages.

This looks like a Windows tree and doesn't seem to do anything other than open and close. I thought our tree was already a good deal more advanced than this? But maybe I'm not understanding exactly what you mean?

Pete I think we fixed this, but just wanted to make sure you aren't still experiencing this?

I was able to duplicate that here too. I'm not 100% sure why this issue only affects images in user profiles (as opposed to other pages), but the internal uncaching feature causing the problem was not crucial to keep, so I've committed a fix and it's available now. Thanks for finding this.

There should not be any risks to upgrading. All you need to do is replace your /wire/ directory with the new one. You may also want to replace your /index.php and .htaccess file with the new versions, though I don't think those have actually changed at all (so may not be necessary). However, I just want to mention that any time you do any kind of upgrade with ProcessWire or anything else, no matter how minor or major, always back up your database and files. You always want to be able to revert. That's a good best practice to follow in any case.

We definitely need to know which version you are running because it will affect where you check for the access settings. I agree with everything @apeisa said. In addition, check to make sure the page is published– Unpublished pages are viewable to the admin, but not to guests. Lastly, edit your /site/config.php, find $config->debug=false; and change it to $config->debug=true; then view the page again and keep an eye out for errors. I just want to make sure there isn't some error occurring here that might be redirecting it to load the 404.

Thanks for posting and glad that you are enjoying ProcessWire and the forum. I look forward to your new site!

By default, the "Forgot Password" module is not turned on in v2.1. My thought was that lack of such a function is technically more secure (on any site or CMS). Why? Because having such a function active means your password is only as secure as your email (*though see note at end of this message). So I thought we'd start things out as secure as possible and let people adjust it according to their own need. But I'm rethinking that decision, and may change it to be 'on' by default. If you don't already have that "Forgot Password" module installed, it is relatively easy to reset your password with the API. Lets say that you lost the password for your account named 'admin' and you wanted to reset it. Paste this code into any one of your templates (like /site/templates/home.php in the default profile, for example): <?php $admin = $users->get('admin'); $admin->setOutputFormatting(false); $admin->pass = 'yo12345'; // put in your new password $admin->save(); …or if it's easier for you to copy/paste everything on one line, here's the same thing as above on one line: <?php $users->get("admin")->setOutputFormatting(false)->set('pass', 'yo12345')->save(); Replace "yo12345" with the new password you want and save the template. Then view a page using that template (like the homepage, in our example). The password for that account has now been reset, and now you are ready to login. Don't forgot to now remove that snippet of code from the template! Otherwise your password will get reset every time the page is viewed. Once logged in, here's how to install the Forgot Password capability: 1. Click to the "Modules" tab. 2. Scroll down to the "Process" modules. 3. Click "Install" for the "Forgot Password" module. That's all there is to it. You will now see a "Forgot Password" link on your login page. *ProcessWire's "Forgot Password" function is actually a little more secure than what you see in most other CMSs. Not only do you have to have the confidential link in the email, but the link expires in a matter of minutes, and PW will only accept password changes from the browser session that initiated the request. So an attacker would have to initiate the password change request and have access to your email at the same time, making it a lot harder for a man-in-the-middle snooping on your email.

Just want to clarify that it's not about hiding output, but about turning the formatting off. So your code would look something like this: <?php $page->setOutputFormatting(false); $page->comments->add($c); $page->save('comments'); $session->redirect("./"); // or $page->setOutputFormatting(true); Note that redirect at the end. It's not entirely necessary, but it's something that I like to do just so that I'm getting a fresh copy of everything and preventing the possibility of having the user hit reload and re-posting the same thing. If you don't do the redirect, then you'll want to turn outputFormatting back on again. Also note that you'll want to do all of this before you've output anything. So that means moving your comment saving code up above the code that outputs comments, as well as above any header includes or the like. This is only necessary if you are using the redirect, but I think it's a good idea either way because the comment the user just submitted could then become part of the output. If you are finding the comment is not getting saved, try a couple things that might help us to narrow down what's happening. First thing is to temporarily change your $page->save('comments') to $page->save(); If that doesn't make any difference, try adding $page->trackChange('comments'); before the save(). This is stuff you shouldn't have to do, but I'm hoping it might help us to debug.

Good call, I'll put multiple emails on the to-do list. This module may seem like a lot of effort for something rather small, but this is a feature a client wanted so it got built… and figured others may have run into the need before too.

What error message are you getting? If not getting an intelligible error, edit your /site/config.php and find the line that says $config->debug = false; and set it to true. The only thing I can think of in looking at the code you posted is that you might need to add a $page->setOutputFormatting(false) before your $page->save(). But if that's not it, I think we need more details on the error message.

You'll definitely still want to have server-side validation. The JS validation will only keep out the good guys that accidentally selected the wrong file. The bad guys (many of which are automated) will blow right by the JS validation. However, if files start in a quarantine (non-accessible) area, and you use the ImageSizer class, that will throw an exception if something isn't an image. As long as you catch the exception and unlink the file (like in the previous example) that may take care of your server side validation. Still though, I would recommend checking the file extension before doing your move_uploaded_file(), because you can do it with just one (albeit long) line of code: if(!in_array(strtolower(getExtension($_FILES['imageUpload']['name'])), array('jpg', 'jpeg', 'png', 'gif'))) die("Invalid file"); I actually have no idea why you are getting this error. Are you able to see the image on the page, but just can't delete it? Let me know if it's consistently reproducible, and make sure you've got the latest PW version, just in case. Assuming profilephoto is a multi-image field. <?php $photo = $user->profilephoto->first(); // or whichever one you want to delete $user->profilephoto->delete($photo); $user->save(); // You can also do this, to delete all the photos in the field: $user->profilephoto->deleteAll(); The ImageSizer is taking care of moving things around behind-the-scenes, so you can treat it as if it's operating on the original image. Technically, it's creating a new image, resizing it, deleting the original, and renaming the new one to the original's filename. But the point is, your $filename is staying the same so just keep using that. You don't need to retrieve the filename from ImageSizer since you already have it.

I could be wrong, but I think your session.gc_probability being set to "0" means that the session garbage collection will never run. This should probably be changed to 1 (the default for PHP). But as previously noted, Drupal sets both gc_probability and gc_divisor, so I've been wondering if PW should too.