netcarver

@WillyC I think yellowled's point is a little different - perhaps I read the post wrong. Anyway, detecting the use of an email address in a username field & telling the user to use a username doesn't feel like an information leak to me. At best you are providing a binary chop of the input space letting the hacker know that this field really is for a username and not for an email address. In other words, I think it's okay to say... "Hey, this field requires a username, not an email address!" ...but not... "User `WillyC` doesn't exist. Please try again." A generic 'reset message sent' regardless of if the user is known or not should be shown if the input field has the right type of data.

Wouldn't a new desk have worked out cheaper?

Hello @yellowled Would it be worth starting an issue on github for this?

@Valery So it is. Just opened an issue for this.

Perhaps just use the get method for the fields you want and format them as needed? (definitely entity encode them at least)

@Manaus To answer your question directly (but probably in-appropriately and very simplistically): any format that allows scripted actions ('pdf' with embedded JS, 'doc', 'docx', 'xls', 'xlsx', 'ppt', 'pptx' with macros) are more exploit-prone (in my view) than others. However, that does not mean that the others are exploit free. About a week ago there was an exploit announced for 'rtf' files and there have been multiple exploitable problems in rendering various image formats for years. Those file formats that require little to no interpretation to render (basically 'txt') are probably the safest - but even then, not guaranteed non-exploitable as even text files have to be displayed by something and that something might have a bug. Exploitability of a file format is not as simple as just the internal format of the file either - it will depend on both the software being used by the viewers of the uploaded files and how security aware each of them are. Software example: Some pdf viewers might have a rendering bug that allows a malicious pdf file to compromise a machine running that viewer - whilst another viewer of the same file might not be vulnerable to the same exploit. Here's a user security awareness example: Some users turn off macro scripting in MS Office/Libre office (or JS scripting in their pdf viewer) whilst others keep it set to the default or even turn it on - and are therefore more vulnerable. Some Windows users create a non-privileged account and log in under that account - and will probably not suffer from many security issues because of this one action - but the vast majority of users will stick with the initial, privileged, user account created on their machine and are therefore at high risk. To evaluate what file formats to accept on upload is going to require more input than just an answer to your initial question. Your client obviously thinks there is some value to allowing all those file types but you'll need to look at not only at how problematic the formats are that you want to allow but at the risks and probabilities of damage to the client's business of uploading a bad file in any particular format. For example: If the client only allows uploads from its IT staff and only allows its janitorial staff to download the uploaded files then the risk to the business from a bad pdf file might be close to zero. I can't really give you any advice on how to do that risk assessment other than to start asking 'what if' questions about the scenario the client is proposing to you. 'What damage would be done if a malicious, even a previously trusted, user uploaded an infected powerpoint for our Chief financial officer?' 'What damage would be if a malicious docx file could masquerade as a valid rtf file and be uploaded?' 'What if my clients don't have a clue how to secure their own user accounts?' 'What if my clients are going to trust uploaded files from any source?' Etc, Etc. HTH.

Added new transforms... "initial" - Pulls the initial letter of the first word of the field. "initcap" - Pulls the initial letter of the field, capitalises it and appends '.' "initials" - Pulls the initial letters of words of the field. "initcaps" - Pulls the initial letters of words of the field, capitalised and postfixed with '.' "thinspaces" - Replaces multiple spaces with a single space. (integer) n - Selects the nth word of the field. Also fixed a PHP notice.

@pwired. Ok. But I'd be tempted to call it something other than "live" chat if that were the case.

Just curious: who are you going to have online 24*7 to take care of the users who want to livechat when you are asleep? Or are you wanting to allow the site's visitors to chat amongst themselves?

@marco Do you have xdebug installed on that machine? If so, check out the documenation on how to increase the max nesting level.

@adrian I missed that, so yes, it is probably right then.

@wtrainer I'm just looking at the path reported in your error message; "(in /home/madabout/public_html/subdomain/wire/wire/core/ProcessWire.php line 143)." I suspect that the ".../wire/wire/core/..." should only be ".../wire/core/..." which makes me wonder if the zip extraction was to the right place. I don't know but it's the only lead I can give you at the moment. Personally I install PW using "git clone" directly from the repos and that saves me having to worry about extracting to the right place. Anyway, hope you get to the bottom of this.

Krebs has just posted some guidance about heartbleed that might be of interest. FWIW, the Lastpass SSL checker is showing Processwire.com as vulnerable.

@pwired, I'm glad you got your issue sorted out! It seems I may be wrong about notepad if it does let you choose the encoding - apologies for that - perhaps it has been improved in the last 10 years. Switching to Ansii definitely kills the BOM but it will limit your ability to use UTF-8 characters in your PHP even if you don't use them directly in the HTML. So I'd still recommend using a fully fledged programming editor over notepad. Personally, I use vim as my editor and you can set it up to show "whitespace" characters. It does have a long and steep learning curve though so you might be better served by notepad++ or Sublimetext2. I've not had any trouble with BOMs since I stopped using Windows and switched to Linux & vim as my editor. If your webserver and HTML headers are serving your pages as UTF-8 then sending only Ascii chars will be fine (they are a subset of UTF-8) but pretty limiting, especially if you ever need to use a language other than English at any point. UTF-8 without BOM does seem the way to go for webpages (at least at the moment.)

@pwired If you are learning about programming/developing then do invest time in learning some quality tools as you'll use then a LOT. Getting a good development toolchain and workflow setup will repay you many times the investment you put in up front. One thing you don't wan't to screw around with is a sub-par editor like notepad that doesn't even let you chose the character set to save a file in especially if you are pasting in snippets from all over the internet with diverse character encodings. You will waste your time and ours if you continue down that road. Do yourself a favour and learn something powerful like vim, textmate, sublimetext2 or one of the better IDE editors.

@wtrainer What permissions does MySQL user "madabout" have? Make sure they can create and insert into tables. Also, is your web server on the same box as the MySQL server? If not, you probably need to widen madabout's login permissions to allow them to login from a different host.

Don't use notepad: please!. AFAIR it doesn't handle utf8 and byte order marks correctly. Those characters are probably BOMs from the start of the included files. Try to use an editor that allows you to set the encoding and line ending of your files. You wan't to set the encoding to "UTF-8 without BOM" and use linux line endings where possible. When I last used Windows (about 10 years ago now) I was using Notepad++ which did the job really well. There are other options on windows - try googling for "programmers editors windows" or something like that. Once you have a good editor, set it up to save using UTF-8 no BOM and re-save all your files from it. I'm guessing that will solve your issue but cannot guarantee it.

@adrian Just started using this on a test install and it's fantastic. I agree with Soma that being able to choose a template for the parent (container) page would be good as I can envisage using a common container template for different sets of children. I think your module would also benefit from allowing user override of the generated parent and child template names. For example, I'm going to be doing a site offering different gymnastic courses so a natural name for one of my containing parents is going to be 'Courses' which gives rise to the template name of 'courses' (which is fine) but I'd like the template for the children to be the singular 'course' rather than 'courses_items'. You could probably accomplish this by providing a field for the child template title and having it filled on-the-fly as the parent title is edited in the same way a page name is populated as the page title is entered (if not already edited by the user.) The workflow would then look something like... Enter the parent title: "Courses" (the child title automatically becomes "Courses Items" by default.) Edit the child template title, changing it to "Course". Fill in the rest of the page & submit giving parent template title: "Courses" and name: "courses", child template title: "Course" and name "course". In this way, users could title and name the parent and child templates as needed. The child template title field could be collapsed by default as it can safely be ignored if the user isn't picky about the child template title/name. Not sure how easy or difficult this might be but having a way to specify field types when using option 2 might be useful too. Maybe something like... Title, Min Age>Integer , Max Age>Integer, Gender Though there will be better ways to express this. I'll keep playing and post again if anything more comes to me.

@adrian After drawing up a spec. on the back of an envelope (ok, back of a timetable) for a module to allow the fast creation of sets of pages plus the templates and fields needed for them I decided to browse the modules repo and found your module. Thanks for saving me some time with this one

@bytesource Thanks for that. I've fixed it and pushed it up to github. Regarding installing the new version. I'm not sure about the 'official' way to go about this but I think Ryan will have orphan checks built in to the code so you can't just un-install things that are in use. As the new version still provides exactly the same formatters as before I'd try backing up the existing folder (somewhere out of your directory tree) then dropping the new module in its place and then hitting the 'Check For New Modules' button and seeing where it gets you. Otherwise, switch the old folder back in, remove the formatter from your fields, deinstall, switch out etc.

@Mats No problem - I forgot I could add that PHP dependency as a requirement in the plugin info. I'll fix that. Edited to add: Updated the module to require PHP>=5.3.0 which should stop this occurring again.

That looks good. What version of PHP are you using?

@Mats Thanks for the report - I'll try a fresh install via the Module manager and see if I can reproduce this. Updated to add: Worked fine for me using the PW dev branch and PHP 5.5.11. Could you paste-bin/gist the content of your TextformatterTextile.module? Sounds like it might have been corrupted.

@all I just pushed a waaaay overdue update to the Textile textformatters that brings in the latest version of Textile (now at 3.5.5 compared to 2.4.1 before.) If you want to see what new features Textile picked up along the way then browse the changelog. Please be aware that this new version requires PHP 5.3.0 or higher as it uses namespaces. This release also introduces a new formatter: TextformatterTextileField. This is a very lightweight formatter that only applies Textile's span and glyph handers to a single line input and does not wrap the result in paragraph tags - making it suitable for formatting fields for use in PW templates without having to resort to stripping paragraph tags.

@bytesource I just pushed an updated TextformatterTextile module that adds a new formatter: TextformatterTextileField that should do just what you need without you having to hook things or use the P stripper.