ryan

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!

The most basic reason is that modules are delivered to the API in a configured state where they have had configuration data populated to them by the Modules class. The module itself can use its constructor to populate defaults. Once init() is called (again by the modules class) configuration data has been populated to the module. Once ready() is called, the API is fully ready (if it's an autoload module). Basically, a lot happens between when the module is constructed and when it's delivered to you. If you just do "new ModuleClass()" then you are skipping over a sequence of events that is important for some modules and not for others. So it's a best practice to use $modules->get('ModuleClass') rather than new ModuleClass, so that you don't have to worry about what initialization does or doesn't need to occur in a module based on it's configurability, singular and autoload status. This looks great! I can't wait to try this one out tomorrow (only on mobile this evening). Nice work.

When I'm importing pages and I need to import quantities above 1 million, I usually try and limit it to 450,000 new pages at a time. It is true though that the more memory and execution time you provide, the more you'll be able to do. You also might find advantages to doing this from the API rather than ImportPagesCSV, as you've got more control over memory usage. Though I can't think of anything offhand that would be a memory concern in ImportPagesCSV, but also haven't tried it on a CSV file with 1.8 million rows. Still, major respect for at least attempting to take PW into the 1+ million page territory. Not many have done that, but you can.

This is now fixed in the latest commit. https://github.com/ryancramerdesign/ProcessWire/commit/4b5f8e7aacd56d52dd82f84211870d20492d7520 Basically was converting something to an integer that shouldn't have been converted. Only appeared to affect pages named "0", but the fix was easy and well isolated. Thanks to Nik for helping me to track it down.

Thanks Alan. Funny I thought I'd already fixed this a long long time ago. And actually I did, but turns out I just hadn't pushed it to GitHub. But went ahead and did that so should be fixed now.