netcarver

@teppo Great link! Learning some new things from it. Thank you.

@teppo I don't think Tom wants to have his users click to open the field. He just wants the locked value displayed uncollapsed.

Ok, I found that they are using the class name. I think the Japanese and Chinese entries would be better shown in their own scripts - 日本語 [JS: \u65E5\u672C\u8A9E] and 中文(简体) [JS:\u4E2D\u6587(\u7B80\u4F53)] - respectively. Will PW or PHP choke on these if they were renamed at some point in the future? I'm not sure they will, as some of the languages are currently using unicode points from their own scripts.

I've looked through several of the language packs under the module repo but I can't find out where the language names shown in the image below are defined. Can anyone point me in the right direction? Update: Are these fields derived from the module's class name by any chance?

@all Just pushed v0.6.0 adding... Config of watches using empty strings (detect changes from empty->non-empty or vice-versa.) Hookable triggerMatch() method - so you can define your own actions when a watch triggers.

Then all you need to do is retrain two sets of users; those who think all their work is of minor importance and those who think all their work is of major importance. ;-)

@Soma, Thanks for confirming that. So if I want to use a repeater presumably I'll have to have the module add a page under setup and use it in there.

I'm just getting used to using repeaters in pages (yeah, I'm slow) but haven't been able to find out if they can be used as part of the InputfieldWrapper returned by getModuleConfigInputfields() for configurable modules. I suspect they can't but would be happy if I were wrong. Can anyone give a definitive answer?

Just bumped to v1.5.0 adding new transformations... "nospaces" - Removes all spaces from a field. "nl2br" - converts newlines to HTML breaks. "nl2spaces" - converts newlines to ASCII spaces.

@Macrura No changes that I'm aware of; it's the tagParser module that takes care of constructing the email subject and body lines and that hasn't changed for a few days. However, if the field with the embedded breaks is in the email subject template then those fields will be truncated to prevent email header injection attacks. You should be able to use fields with breaks in the email body template without issue. Is your issue occurring in the subject or body of the email? BTW, I just added a new transformation to the TagParser to help deal with this if it is indeed the situation. Take a look at "nl2spaces" which will strip newlines and replace them with spaces. Might not be exactly what is needed but it is, perhaps, better than nothing.

@Vineet I've never used Amazon's AWS offerings (only Amazon MWS - which is quite different.) I recently posted about my VPS experiences here. You do need server admin skills if you are going to go down the VPS route unless the client can provide those or self-host their service. You might also look at something like turnkey linux's hosted services or even bitnami's new PW bundle (though I've never used these myself.) A quick note on learning server admin skills: there are some great documentation resources (like how-tos) over on the slicehost and linode websites for learning these sort of things but don't buy their services just to learn how to admin your system - simply install virtualbox on your desktop machine and install something like a Ubuntu server 12.04 LTS client and learn how to do the things you need locally first. Once you know how to setup the server and keep it ticking then you can progress to a paid-for-VPS. Forgot to say, that I've heard really good things about Linode and Slicehost when it comes to more up-market hosting. Never needed them myself.

Hello @Vineet, I'd like to advocate against forcing frequent password changes if I may. IMHO it encourages poor password choice by users as the frequency of changes either causes them to repeat a simple pattern of passwords (like 'password1' one week, then 'password2' the following week and back to 'password1' after that) or it forces them to write down the password on a post-it note on their desk if your policy only allows diverse or strong passwords. I would definitely suggest going down the 2-factor authentication route (and yes, I published a 2-factor authentication module for PW) as this significantly mitigates poor password choice on the part of users anyway. Also, I don't think your client should be running a service with any sensitive data on a shared host. VPSs are pretty cheap these days.

If you are new to PHP then you might find the resources at php.net really useful. There's documentation for the entire language including every function.

@all Sorry, looks like I pushed a bad version. I'll fix that. Sorry, false alarm - it was a problem with a local change that wasn't added to the code I pushed.

@all I've updated the module to allow parsing of page subfields, fix xdebug notices, move DB queries out of the init method and make the strings translatable.

@Macrura, Off the top of my head: could you try making a small change to the ProcessFieldChangeNotifier.module file? After making the change shown there, you should be able to access the page context using 'page.subfield' from your templates but I haven't verified this yet. YMMV

@Macrura, Glad to hear it is useful to you. My original plan was to watch fields regardless of the page context so there's no direct way to do this at the moment. I'll look at adding the page context for the parser.

Once this idea is proven and stabilised, would it be a core module candidate?

Ah, then take a look at www.sharefile.com - there are some very nice features. It is not self hosted though.

Here's another self-hosted option that might suit you: Lipsync (On github at https://github.com/philcryer/lipsync) and attached is a presentation to go with it. DEFCON-19-Cryer-Taking-Your-Ball-and-Going-Home.pdf

@felix, I haven't used it but, coincidentally, this week's episode of FLOSS Weekly is about Seafile.

Ok, didn't realise that was the ballpark. That's about 85 channels more than I've ever used.

@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?