ryan

Glad you got it solved. But I'm confused, how is a Page field linking to a template?

I figured we were talking about some condition other than required? But if that's the case, Soma is right that this is built in. However, it's not going to unpublish a page if you leave a required field empty. Though it won't publish an unpublished page that has a missing required field.

Hope my writing isn't coming off the wrong way -- this is good discussion and collaboration to me. I've been neglecting my duties at the forum for the last few days and trying to participate better now that I had a little break today. I'm having fun, learning and hopefully contributing something worthwhile too. Soma if you view this our any of our past interactions as confrontational in any way (which the word 'war' implies), I apologize because I felt much the opposite. Stubborn really? My wife will think that's hilarious, she thinks I'm a gullible pushover.

Looks good, thanks for making it! This login is meant for the admin, but when building your front-end site login, it's just as simple to use email address as it is name. Likewise, this is where I'm guessing the other types of logins (twitter, etc.) would be more likely to be implemented. But even if for admin, I really like that this module opens up the option to login by email and think others will too. I'm not sure I agree that it should be built-in, as I want to pick a consistent standard and stay with it. So I actually think it's a perfect use case for a module, and think you solved it very nicely. The only concern with using email addresses as logins is that they aren't guaranteed to be unique. After all, email is just a ProcessWire fieldtype (not something built into the pages table) and someone could be maintaining two accounts with the same email address (as I often do). So when building this functionality on the front-end, I usually do something like this: $us = $users->find("email=$email"); foreach($us as $u) { if($u->pass === $pass) { // found the right one } } I add hooks for anything that people want. But they don't get that way until someone asks for them. There is naturally a little more overhead associated with a hook function than there is with a native function, so I don't want to go off and make everything hookable just because it can be. It takes very little effort to make something hookable (just adding 3 underscores to the beginning) so it would be easy to get carried away with it. I can't predict everything that people would want to hook, so instead let the users decide what they want to hook and I add those 3 underscores and we're done. Easy. All you have to do is ask. If there is one thing I can do quickly, it's type 3 underscores. Your ReflectionClass hack may not be necessary (though I did think it was quite a cool hack). Instead, I think you may be able to do this: $form = $event->return; $field = $form->get('login_name'); $field->label = $this->_('E-mail Address');

i tried moving the repeater into a fieldsettab, but still works as it shouild. The only thing I can think of is that you might want to upgrade your PW version. I'm running 2.2.7 and you are running 2.2.3, so that seems to be the only obvious major difference at present.

The name of a template really shouldn't matter since anything referencing it stores it as an ID (number). But it sounds like that old template name must be somewhere, somehow. I'm assuming the new template name is "page_parc". Have you tried changing the template name back? And if so, did that fix it? What 3rd party modules are installed? Are you using any "cache" fieldtypes?

No doubt, and I intend to. But you mentioned you've tried every IDE that there is, so clearly you've been trying to fill a need or desire that you have. I do not share this need or desire, and I come from a background of using IDEs... but I used them (at work) because I had no choice. Give me a choice and I'm far more creative and productive when there's nothing between me and the code I'm trying to read or write. Yes that means there's more to think about, but perhaps the creative juices just don't flow for me unless I cross that threshold (must be ADD). The only reason I will even look at StormyPHP and SlimeText is because it'll make you guys happy. I'll congratulate you on your decision, and enjoy the opportunity to play, but won't become a convert. I'm quite happy with the environment I work in and don't have any needs, desires or bottlenecks I'm looking to solve. Otherwise I'd be deeply invested in trying lots of IDEs too. Instead, what I'm interested in is learning how to make the code as accessible as possible to people that do use these tools and want to browse from above rather than within, provide them with the context they may be missing, and prevent them from going down the wrong path. I fully support anything that aids in understanding for as broad of a group as possible. So if there are some specific things that I can do, I'm hoping you can help to point them out. What specifically would make your experience better when viewing ProcessWire code from PhpStorm (or SlimeText, etc.)?

In a broader audience context, I think this would be more accurate to say "build software for the future, not the present". The reality is, we have a whole lot of people still on PHP 5.2.x, so that still represents the present to many in their environment. When building stuff for yourself, a client or smaller group, I think your attitude is the right way to go. But when building stuff for a worldwide audience, you only sacrifice your potential audience size by coding in a way that isn't backwards compatible with a still sizable chunk of active servers. Is it more beneficial to use an anonymous function, or is it more beneficial to be accessible to 20-30% more people? For ProcessWire--a project where we are trying to grow our user base--accessibility with 5.2.x is a greater benefit than using 5.3.x specific syntax (though this will change quickly). I don't fault you for wanting to limit your module to 5.3 and above. But I think your statement is contextual to your situation, not ProcessWire's audience. Personally, I can't wait to be exclusive to 5.3 and above, but the time isn't right just yet. When every other site that someone asks me to check out isn't running on 5.2, then the time will be right, and it can't come soon enough. I've gone through it and tested it all out and think it looks really good. Nice job! But since you asked for a code review, I'll make a few minor points: 1. There isn't consistency with use of starting "{" characters. Some start on their own line, others at the end of a line. ProcessWire's code standard is to never have a "{" character be the only thing on a line. But this is not applicable to 3rd party modules, so the only thing I would say is to pick one and stick with it. 2. There are very few comments in the module, and what comments there are most just point out the type for implied variable names. This isn't a problem for me, as I thought your code was strong and self documented very well without comments. But since we're discussing this in another thread, I thought I should point this out since you asked. 3. I have a little trouble following the code due to the narrow indentation, but I think that's only subjective and not something you need to worry about unless doing pull requests in the PW core or something. We use tabs rather than spaces in the core, but of course it doesn't matter what you choose to do in your own modules. 4. In your init() function, it would be preferable to skip attaching the hooks if they aren't going to be applicable in the request. What I would suggest is to add a ready() function and move all your 'addHook*' lines into the ready function. Then do something like this: public function ready() { if($this->page->template != 'admin') return; $this->addHookAfter('...'); // and so on with the rest } Basically, there's no reason to attach the hooks you are attaching if the template isn't admin. You could even get more specific if you wanted to… if($this->page->process == 'ProcessTemplate') { // add your ProcessTemplate hooks } else if($this->page->process == 'ProcessPageList') { // add your PageList hooks } …but I think it's fine just to check the template. Ultimately, it's not a problem to stick with what you are already doing. But I'd consider it a best practice to apply some conditions to your hooks. 5. Other than being fun to do with PHP, I'll be honest and say I don't see the benefit of using a closure in your hookAddForm function vs making it a class function. I think the code would be more readable without it, but this is only subjective. So I'm just stating an opinion here, not suggesting you change it. 6. Your hookAfterRender function both adds a JS file and produces an inline script. Why not just move the contents of the inline script to your TemplateBadge.js file? This seems like unnecessary extra code that doesn't need to be in your .module file. 7. Moving into the UI: The select box could use a little more space between it and the icons (at least in Chrome): 8. You may want to add an 'author' property to the array returned by your getModuleInfo() function. That's all I've got. I'm being picky here because I know that's what you want. But I also want to tell you what a great job I think you did with this module and how visually useful the result is. I love what this does for the PageList, so nice job! I have updated the ProcessTemplate::buildEditForm to be hookable and it should appear in the source later today. I'm testing out the latest jQuery in ProcessWire, but running into some problems there. For instance, why does a statement like this stop working in jQuery 1.8? var $buttons = $("#content a[id=] button[id=], #content button.head_button_clone[id!=]"); jQuery 1.8 returns a blank array [], but jQuery 1.6 and prior return the items that match the selector. It's these little changes in jQuery that drive me nuts, and the reason I don't upgrade immediately every time they release something new. But unless I'm missing something (very possible), this seems like a completely valid selector that breaks under jQuery 1.8. My best guess is that jQuery 1.8 now treats "id=" as "has an ID attribute that is blank", whereas previous versions treated it as "has an ID attribute that is blank OR has no ID attribute", but haven't yet confirmed.

This is really awesome Steve, and a great idea. Just tested out here and it works great! Thanks for your work with this module, it looks really well put together. One question: why is CryptoPPP.module kept separate? Just wondering if this might be simpler for people to install if they could just download 1 zip (or 1 clone) and have everything needed in 1 directory. You could add CryptoPPP to your getModuleInfo 'installs' line, and have it install and/or uninstall automatically with Auth2FactorPPP (ProcessWire will do this for you have you use that 'installs' property). Though if you are planning to make other modules that use CryptoPPP, then I suppose it makes sense to keep them separate. But just wanted to check. I would love to see this in the modules directory if you have time to add it: http://modules.processwire.com/add/ … thanks again for the great work you've done with these modules!

Do any modules need a newer version of PHP than ProcessWire itself? Guess it's never come up before, but I suppose it could. PHP actually has a very handy function that you can use from your modules to compare against the PHP version or ProcessWire version: if(version_compare(PHP_VERSION, '5.3.0', '<')) { throw new WireException("You must have PHP 5.3 or newer to install this module"); } if(version_compare(wire('config')->version, '2.2.7', '<')) { throw new WireException("You must have ProcessWire 2.2.7 or newer to install this module"); } I was thinking about making the PW version designation part of the getModuleInfo array so that PW would enforce it internally.

There has been a recent change in behavior here (a couple weeks ago), though not one that affect you unless you are trying it for the first time, as there was nothing worthwhile in the previous behavior. PageArray::sort() used to sort by the property value without regard to the page's outputFormatting state. This would mean that it could sort by the formatted date, which would be alpha sorting (of the date string) rather than date sorting. That's really not what you want. So I recently modified it so that it always sorts by the unformatted value, regardless of whether output formatting is on. Meaning, $pageArray->sort('some_date_field'); and $pages->find('..., sort=some_date_field'); should always be consistent. Please let me know if you are up-to-date with your PW version and still experiencing incorrect behavior with this.

Not yet. Lots of context and security considerations with this that are different from what they would be on the admin side, so going to approach this inputfield separately from the ones already included with PW. However, anyone that purchases FormBuilder now will get file/image fields (and a lot more) as soon as they are ready.

Is it possible that your web host moved your files from one place to another (perhaps forgetting to retain the permissions?). It could also be possible that they've got some script going through and changing permissions on you (I've seen this at Media Temple once). Also want to mention that the permissions you indicated (rw for user only) will only work if PHP is running as a CGI or PHPsuexec. Those permissions simply won't work on a lot of web accounts because Apache (often running as Nobody) needs to be able to write to the directory.

There should be no problem with using a multi langage field in a repeater. Just tried to do it here with a PageTitleLanguage field and it worked. What version of PW does it say at the bottom of the screen?

I appreciate your point of view, but understand we're coming from different preferences in this regard. As you know I'm not an IDE fan and my focus is on code best practices, not IDE navigation. I care more about program comprehension, design and code review than static analysis. I veer towards putting my time towards the practices and documentation that best serve and maintain the code base quality, as opposed to accommodating one or another automated tool for static analysis. To put it another way and use the same term you did: I would rather put my clock cycles towards the things that best help code review and overall quality than the things that maximize someone else's static analysis and IDEs. But don't get me wrong, I have nothing against supporting these tools and maximizing the experience with them. As you know, almost every class and function in PW is documented, and most with phpdoc. If time were unlimited, I would take full advantage of communicating above and beyond to everything that PhpStorm (or another IDE or tool) could want, even if it doesn't help me. And over time and within resources, I support this (@interrobang has helped out a lot recently in this area). If there are things that would be beneficial to you in PhpStorm (and you think woud be valuable to others), call them out more specifically so we can get them on paper and make it part of the roadmap and collaborate on implementation.

PHP interfaces are the way that you deal with being able to identify something that is going to have this or that known method. Basically back to this. There's not anything different built into ProcessWire that would accomplish exactly what you are talking about, but of course you could manage your own registry for a custom need. I would avoid anything that relies upon using method_exists() just because that's only telling you that a method name exists and not that it's going to have the expected arguments and return, etc.

$user->language = $languages->get('de');

If the request comes in through ajax, ProcessWire will detect it and your Process module can just return the content (JSON or whatever) that you want in the ajax. Basically, you don't need to do anything other than load the page with ajax and you should get what you want.

I agree with Pete about ServInt. I've used their service for longer than I can remember. They are the real deal. Unlike something like Linode, they are considered "managed", which I think most non-sysadmins like me need. This site (processwire.com) runs from their McLean, VA data center. Their Amsterdam data center is relatively new, but they've had a great reputation here in the US for more than a decade and sounds like they are upholding that reputation in Amsterdam too. Given that most of our traffic is from Europe, maybe I should move to the Amsterdam data center, but I'm a little nostalgic for McLean, VA (I grew up there). Most of my client sites run from ServInt as well, and they've been the only company I deal with that I never have to worry about. At the other end of the spectrum is Media Temple -- a real ball and chain, to put it mildly. As for super-budget hosting (which I sometimes need), I've had decent experiences with both HostGator and BlueHost. But I'd never put something I really cared about on this type of hosting.

Mike, maybe for next year's CMS awards we can get it setup on Form Builder, which keeps out spam with honeypots, Akismet and a Turing test. The advantage of honeypots and Akismet are that the user never knows there are spam prevention measure in place (unless they submit spam), as it all happens beyond their view. The turing test option is within their view (if you decide to use it), but it's up to the administrator to decide how simple or difficult to make the test. Recaptcha would qualify as an extremely difficult Turing test. I don't blame you for using recaptcha. If that was the only choice I would choose it in a heartbeat over an unprotected form. Having built a whole lot of forms over the years, spam would fall near the top of my list of considerations on any form, so I respect use of recaptcha even if it's become a lot more difficult to solve lately.

That's a new trick I didn't know about -- I like it. I have no idea how to do what you are asking, but guessing Soma (our resident TinyMCE expert) might.

In this case I would agree, so this particular validation (password) is at the input level (inputfield) rather than fieldtype. So even though "yo123" would be perfectly fine at the API level, Ralf was right in pointing out it's not consistent with our recommendations for passwords. It's up to the inputfield or fieldtype module author to decide on the details, but a good rule of thumb is that input validation is typically the job of an inputfield, while page data validation (API) is typically the job of the fieldtype. Fieldtype validation is more about integrity of system data, while Inputfield validation is about enforcing rules within the data that is input.

Hard to tell without having the full thing in front of me to step through live. But I'd suggest performing a redirect after a login or logout, so that you are starting with a fresh request, rather than a page pre-login with login happening behind the scenes. Seems like there is possibility for some session conflicts there, though again not positive without experimenting on the live code.

Sounds good to me. Though something to consider is that you may be unpublishing a live page from the site, which could be undesirable in many situations. Depending on the situation, it may be better to save the page and notify the editor of the error rather than fully unpublishing it.

I'm excited to announce that the ProcessWire Form Builder is now available from the DesignIntelligence bookstore: http://store.di.net/...re-form-builder I'm initially giving a 20% discount on the prices there (coupon code PWFB-BETA) because I'm still adding new things to it at a rapid pace, and feel it should still be called "beta test" (and not full price) until it's been out in the wild for a bit. However, a few of us here have been using the Form Builder on production sites for awhile already, and it's working great. But if you don't mind using a pre-release version and giving me feedback or suggestions where appropriate, then there's a nice discount for now (which will expire when we reach version 1.0). If you are wondering what the DesignIntelligence bookstore is, they are one of my long time clients and have agreed to let me provide the Form Builder through there. I actually setup and manage this online store already for them (and have for years), so feel very comfortable putting the Form Builder here. But when we grow big enough, we'll setup our own. When you get Form Builder, you'll also get access to the new Form Builder Support board (in this forum). This is where regular software updates are posted (ZIP files), among other things. So PM me when you do so that I can add you to it. Thanks for your support of ProcessWire and Form Builder!