Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 02/24/2014 in all areas

  1. I didn't know this one Shortest way to echo a variable only if populated (using pw fields of course ): echo $page->field?:''; and: echo $page->field ?: "field is empty"; // echoes field content echo $page->empty_field ?: "field is empty"; // echoes "field is empty" or even: echo $page->field1 ?: $page->field2 ?: "they are all empty";
    7 points
  2. Of course there can be security issues on pw. And since it is full framework instead of just sandbox for simple sites, developer can create bunch of holes themselves. But so far there has been zero vulnerabilities found from pw or pw admin. Of course it doesn't have millions of eyes watching like more popular frameworks out there. But all the most common web security pitfalls are very well taken care of in pw. Things like session capturing, brute force login, crsf protection, password encryption, sql injections... no software is 100% safe, but what comes to processwire, I know that we have pretty darn great foundation.
    6 points
  3. The security issue in PW would Be The devloper.
    3 points
  4. As far as I know, there has not been a security issue in PW since I have been using it (which means since 2.2). By that I mean there has never been a “OMG, big issue, everyone upgrade to the new version of PW ASAP!!11” situation. Knowing other CMS out there, that's pretty amazing. Is this true? Has there never been a security issue (which the public would've known about)? If so, why is this? Is it because of the way PW is developed or something? The reason I'm asking this is that I realized I don't know the answer myself, and of course, this does come up in talking to clients. Also, I will be giving a presentation on PW at a German web conference soon, so a definite answer to this might be nice.
    2 points
  5. Shortest is to just echo $page->field. If empty it will not output anything.
    2 points
  6. Something to get you started: http://processwire.com/talk/topic/1932-security-sql-injections/?p=18127 http://processwire.com/talk/topic/4426-pushing-pw-in-web-design-agencies/ And more.... http://bit.ly/1fxHHux Good luck with your talk! I know you'll do PW proud!
    2 points
  7. An option until this is fixed is to either FTP the AIOM folder to the /site/modules/ directory on the server or Go to Modules and click New and add the Module by typing in the Class Name.
    2 points
  8. Just added a new forceSecure option to the config. Also made sure that if port is left blank, that it sends NULL, rather than blank which seems to be a requirement. Also added a fix for the HTML vs text email issue reported by @martind All these will go to another PR for Pete in a few minutes. Please let me know if the attached version works for you now. My forked version
    2 points
  9. Hello, I've been developing sites with ProcessWire for a while now, and all those sites have been performing really well. It's a good enough proof that PW itself is very efficient & well performing system but I'm not sure how efficient coder I'm. Just wanted to learn from you guys, what are the things you do to keep PW's page structure clean, few good practices you follow & how do write smarter code that reduces server load, etc. For example, I learnt following things from tutorials that I always do for every site: Creating a site settings page to store all global static variables in one place such as site logo, site title etc. Using globals.inc file for regularly needed variables, functions & information Under home, creating ajax/json (locked & hidden) pages for processing forms Using tags to group fields & templates Prefixing field names with template name for easy identification Naming similar or related templates & template files with similar prefixes Thanks!
    1 point
  10. I am curious as to the name of your images field. That error you are getting makes me think you don't have a field called "images". The module currently has the field hardcoded as "images" so clearly that needs to be made flexible so that other fields can be used. Not sure the best approach for this though. If there is only one image field in the selected template, it's easy, but if there is more than one we'd have to either just choose the first, or ask what field to use in the config settings, which might be best. Also, if there is more than one image attached, and the chosen field is set to only store one image, then there is also an issue. Also I see that there isn't anything to determine if the attachment is in fact an image which is something that should also be checked, and if it's not should the file be added to a files field on the page? Anyway, please check that your images field is in fact named "images" and see if that helps. I am curious about nothing showing up in the body of your page though. Do you have a "body" field in the selected template? Sorry, I see that you didn't enter any text in the body of the email, so this is expected. Regardless, I think this is something else that needs to be made configurable - at the moment the body field must be named "body" as this is the hardcoded name. EDIT: I haven't narrowed down why yet, but if I send the email from Mac Mail, no attachments get converted to images, but if I send them from gmail from within the web interface, everything works perfectly - maybe there is some limitation with flourish and its ability to detect attachments in some case, or maybe it is the crazy way Macs attach files ANOTHER UPDATE: I just sent an email with an attached image from MS Outlook and it also works perfectly, so I am beginning to think there really is something amiss with attachments and the Flourish/Mac Mail combination. Can anyone else confirm this with the version of the module attached to my previous message? AND ANOTHER: I have added support for inline attachments and this seems to be helping with Mac Mail. I had also been using this setting: defaults write com.apple.mail DisableInlineAttachmentViewing -bool yes on my Mac, but reversing that (change yes to false), along with the new inline support and images are now being added. The one outstanding problem I can see at the moment is that if a Mac Mail message also has text in it, the image won't work, so test without anything but the image for now if you are using Mac Mail. Turns out this needed "related", not "inline". I have added support for this in the new version attached this morning. One other thing I think might be a nice addition to this module is support for embedding images into the body field if they were embedded inline in the email. I need sleep now, but might look into this tomorrow! My forked version
    1 point
  11. Okay, first of all, I have not done that with websites - well, I did many, many years ago with a large community site, but that was chaos! However, I have managed huge event productions and video productions where you have a lot of different talent supplying different technical skills with a lot of overlaps. I also have a nephew who is a lead developer on several very large games. The trick I have found is to try and reduce overlaps and to make sure the main development parameters are set in stone BEFORE anyone starts coding, drawing or anything else. So, everyone should know what it is meant to look like, understand every aspect of the brief (not the client brief, but the one you write as project manager) and know exactly what their responsibilities are right down to what scripts or functions they should be writing. AS part of that process it is worth having a short lived debate on style and structure, then put that in the brief too. Then, when someone goes sick or drops out, their work can be understood. That project brief document is important and is often neglected. The last time I did one was for a community zone for an online game where the community applications would need to talk in detail with the game application. Horrendously complicated! The final project bible for that was 40,000 words long - but nothing was missed out and in the writing of it, we solved huge amounts of tech problems and knew what it would look like, how it would feel and had even tested out how it would work with players and what they thought. It just needed to be manufactured - and it would have been if the people behind it had actually coughed some money up! I am often amazed how many large projects are created on the hoof - but then, going by how many IT projects end up as camels (a horse designed by committee) , it is probably no surprise at all. Imagine Ford walking onto his first production line and saying, "Okay, guys, we are going to make the first mass-produced private vehicle. No, sorry, I have no idea what it is going to look like or how it will be put together, but I am pretty sure it will be called the Model ... er ... something. Right, turn the production line on!"
    1 point
  12. Technology evolves and you just have to evolve when things change. The basics I learned in the 80's are still applicable today. Each new technology builds on, circumvents or basically changes what was hot yesterday. If you are serious about learning you will keep up and prosper. Don't look at new ways of doing things as a challenge, look at it as an opportunity. Don't be scared or hostile to reinventing yourself. Good Luck in your endeavours.
    1 point
  13. First off, I won't stop developing ProcessWire unless I'm dead. But lets say that one of you showed up at my door and shot me, and then I'm gone for good. This is free software and you don't get any guarantees there, no matter what CMS it is or how big the community or adoption of it is. But what you do get is the source code and permission to use it and do with it what you need to. There is far more security in that than any proprietary or commercial system. We should all feel very lucky that this project has attracted such a capable development community around it (more than any project I've ever seen), and there are several guys here that are fully capable of taking over the project if I go down in a hang-glider crash. I'm always reluctant to list off people because there are so many people that contribute to the core and I don't want to forget anyone. Suffice to say, I may hold the keys to the master GitHub account, but this is a project of many developers, at least 5 of which are fully capable of taking over the project if I kick the bucket. I'm certain that some of these guys could do better than me with it. Please don't take that as an invitation to show up at my door with a weapon. But I would suggest this may be better odds than with the bigger projects you'd mentioned. Lets also point out here that ProcessWire is not WordPress–it does not need daily updating in order to keep running. Most sites I build with ProcessWire are running the version they are launched with. With ProcessWire, you do not need to upgrade your site every time a new version comes out. You can generally upload it and forget it, and it'll keep running till the site as long as the server itself is running. What other CMS can you say that for? (I can't think of any) Personally, I think adoption of something like Drupal, Typo3, Joomla, etc. is more of a risk, because you are dealing with a legacy platform – you are adopting technology from 10 years ago. You are also adopting something that is a target for hackers and spammers. WordPress is perhaps the biggest target, and something I've very apprehensive to setup for clients. Ultimately when a company chooses to adopt a legacy platform because "it's what the clients know" or [more likely] what they themselves know, it's a lazy decision. It's not looking out for the clients' best interests, and it's pursuing mediocrity. When you pursue mediocrity, you pay for it in the long run. There is no better testament to that than the legacy platforms that agency seems attached to. 1-3 years after installing [Drupal/Joomla/Typo3/WordPress/etc.] for the client, they are going to be looking for "something different" in terms of the CMS (we all know this) and they won't be coming back to the same agency. The agency that thinks it's playing it safe is really just hurting themselves when they give their clients something tired and mediocre that anyone can give them. Instead, give them ProcessWire, and they'll know you are different and better (a secret their competition does not have), and they'll be a lifetime client.
    1 point
  14. If working on my own personal projects I develop locally on MAMP and then push everything live to the server once done. I don't use Git as much as I should, I need to work on that. For client projects, I have a random domain name that I develop client projects on, I just make sure they're not indexed by any search engines and only the client has the url to watch the site build and progress. Once I'm finished and they're happy and I've been paid I then migrate it to their server. This has worked well for me over the years and keeps clients happy as they can track the progress of the build.
    1 point
  15. I recently had to setup front-end system to handle logins, password resets and changing passwords, so here's about how it was done. This should be functional code, but consider it pseudocode as you may need to make minor adjustments here and there. Please let me know if anything that doesn't compile and I'll correct it here. The template approach used here is the one I most often use, which is that the templates may generate output, but not echo it. Instead, they stuff any generated output into a variable ($page->body in this case). Then the main.php template is included at the end, and it handles sending the output. This 'main' template approach is preferable to separate head/foot includes when dealing with login stuff, because we can start sessions and do redirects before any output is actually sent. For a simple example of a main template, see the end of this post. 1. In Admin > Setup > Fields, create a new text field called 'tmp_pass' and add it to the 'user' template. This will enable us to keep track of a temporary, randomly generated password for the user, when they request a password reset. 2a. Create a new template file called reset-pass.php that has the following: /site/templates/reset-pass.php $showForm = true; $email = $sanitizer->email($input->post->email); if($email) { $u = $users->get("email=$email"); if($u->id) { // generate a random, temporary password $pass = ''; $chars = 'abcdefghjkmnopqrstuvwxyz23456789'; // add more as you see fit $length = mt_rand(9,12); // password between 9 and 12 characters for($n = 0; $n < $length; $n++) $pass .= $chars[mt_rand(0, strlen($chars)-1)]; $u->of(false); $u->tmp_pass = $pass; // populate a temporary pass to their profile $u->save(); $u->of(true); $message = "Your temporary password on our web site is: $pass\n"; $message .= "Please change it after you login."; mail($u->email, "Password reset", $message, "From: noreply@{$config->httpHost}"); $page->body = "<p>An email has been dispatched to you with further instructions.</p>"; $showForm = false; } else { $page->body = "<p>Sorry, account doesn't exist or doesn't have an email.</p>"; } } if($showForm) $page->body .= " <h2>Reset your password</h2> <form action='./' method='post'> <label>E-Mail <input type='email' name='email'></label> <input type='submit'> </form> "; // include the main HTML/markup template that outputs at least $page->body in an HTML document include('./main.php'); 2b. Create a page called /reset-pass/ that uses the above template. 3a. Create a login.php template. This is identical to other examples you may have seen, but with one major difference: it supports our password reset capability, where the user may login with a temporary password, when present. When successfully logging in with tmp_pass, the real password is changed to tmp_pass. Upon any successful authentication tmp_pass is cleared out for security. /site/templates/login.php if($user->isLoggedin()) $session->redirect('/profile/'); if($input->post->username && $input->post->pass) { $username = $sanitizer->username($input->post->username); $pass = $input->post->pass; $u = $users->get($username); if($u->id && $u->tmp_pass && $u->tmp_pass === $pass) { // user logging in with tmp_pass, so change it to be their real pass $u->of(false); $u->pass = $u->tmp_pass; $u->save(); $u->of(true); } $u = $session->login($username, $pass); if($u) { // user is logged in, get rid of tmp_pass $u->of(false); $u->tmp_pass = ''; $u->save(); // now redirect to the profile edit page $session->redirect('/profile/'); } } // present the login form $headline = $input->post->username ? "Login failed" : "Please login"; $page->body = " <h2>$headline</h2> <form action='./' method='post'> <p> <label>Username <input type='text' name='username'></label> <label>Password <input type='password' name='pass'></label> </p> <input type='submit'> </form> <p><a href='/reset-pass/'>Forgot your password?</a></p> "; include("./main.php"); // main markup template 3b. Create a /login/ page that uses the above template. 4a. Build a profile editing template that at least lets them change their password (but take it further if you want): /site/templates/profile.php // if user isn't logged in, then we pretend this page doesn't exist if(!$user->isLoggedin()) throw new Wire404Exception(); // check if they submitted a password change $pass = $input->post->pass; if($pass) { if(strlen($pass) < 6) { $page->body .= "<p>New password must be 6+ characters</p>"; } else if($pass !== $input->post->pass_confirm) { $page->body .= "<p>Passwords do not match</p>"; } else { $user->of(false); $user->pass = $pass; $user->save(); $user->of(true); $page->body .= "<p>Your password has been changed.</p>"; } } // display a password change form $page->body .= " <h2>Change password</h2> <form action='./' method='post'> <p> <label>New Password <input type='password' name='pass'></label><br> <label>New Password (confirm) <input type='password' name='pass_confirm'></label> </p> <input type='submit'> </form> <p><a href='/logout/'>Logout</a></p> "; include("./main.php"); 4b. Create a page called /profile/ that uses the template above. 5. Just to be complete, make a logout.php template and create a page called /logout/ that uses it. /site/templates/logout.php if($user->isLoggedin()) $session->logout(); $session->redirect('/'); 6. The above templates include main.php at the end. This should just be an HTML document that outputs your site's markup, like a separate head.inc or foot.inc would do, except that it's all in one file and called after the output is generated, and we leave the job of sending the output to main.php. An example of the simplest possible main.php would be: /site/templates/main.php <html> <head> <title><?=$page->title?></title> </head> <body> <?=$page->body?> </body> </html>
    1 point
×
×
  • Create New...