ryan

Alan that's good to hear you've had a good experience with MT. My only experience with them is from the (gs) plan, via multiple clients, and it's been the most problematic hosting situation I've dealt with, though it's not all bad all the time. But it's good to hear their plans above that are in a different class. I'm good with this too. Though also think that there isn't anything specific about ProcessWire that makes it require hosting any different from say WordPress, Modx or Drupal. So ultimately it would just be a list of services that members here have had a good experience with. Longer term I think we should have a listing of this sort, but shorter term we'll probably want to keep it to the forum until some other projects are out of the way.

It's meant to be paginated within date ranges using the dateFrom() and dateTo() methods that you can call. Here's an example that uses the Google Calendar Loader and paginates by month/year: http://washingtonwaldorf.org/calendar/ $month = $input->get->month ? (int) $input->get->month : date('n'); $year = $input->get->year ? (int) $input->get->year : date('Y'); $dateFrom = strtotime("$year-$month-01 00:00"); $dateTo = strtotime("+1 month", $dateFrom)-1; $cal = $modules->get('MarkupLoadGCal'); $cal->dateFrom($dateFrom)->dateTo($dateTo); $cal->load('your-gcal-email@domain.com'); echo "<h1>" . date('F Y', $dateFrom) . "</h1>"; // i.e. September 2012 foreach($cal as $item) { // output your items }

WillyC's example above would be the way to do it. The core is specifically built to support that hook exactly the way that he used it, so this is not a hack, this is part of the API (combined with using urlSegments). But maybe somebody will come up with a module that enables it to be automated from the admin at some point. I'm of the opinion that you will see the greatest benefits by using a structure that is consistent with the navigation. So if one is having to redefine URLs outside of the structure, that's a good reason to reconsider whether the chosen structure is ideal. You've got an infinitely nest-able tree (in a manner of speaking). Every branch is its own tree if you want it to be. It's just a question of how you perceive and use it. Regarding labels, take a look at mindplay.dk's Template Badges module, which might have some of what you are talking about.

Sorry guys looks like I neglected to update the tag. So it was 2.2.7, even though the filename didn't indicate it. However, I updated the tag today so it should now say 2.2.8.

Thanks for the pull request John. I will bring this in soon.

Here's one way that you could do that from your module's getModuleConfigInputfields function: public static function getModuleConfigInputfields(array $data) { $inputfields = new InputfieldWrapper(); $name = 'my_page_select'; if(!isset($data[$name])) $data[$name] = 0; $f = wire('modules')->get('InputfieldPageListSelect'); $f->attr('name', $name); $f->attr('value', $data[$name]); $inputfields->add($f); return $inputfields; }

This looks like it should work to me. Just make sure you are executing all of this before you are starting output. If you find it's still not working, examine what values are getting thrown around in there. For instance, if($session->language) { echo "<p>Language is: $session->language</p>"; } Likewise, make sure that the names like 'it' are consistent with the actual page name of the language.

When you use multi-language fields, they all live at the same URL and it's up to the $user->language setting to determine what language gets shown at that URL. Visit this page for more info about the benefits and drawbacks as well as different strategies that you can take: http://processwire.com/api/multi-language-support/multi-language-fields/ I also recommend checking out McMorry & Soma's Language Localized URL module as another possible solution.

I think that your code looks fine, but I'm not sure that I understand the question?

Thanks for this info. It's hard to tell, still not sure where it was picking up the reference to the template from. Please let me know if you ever see it again.

Great suggestions, thank you for this. You are right, those hidden/invisible properties are not well covered at present. Largely because this was one aspect of phpdoc I wasn't aware of until recently. @Interrobang actually added the appropriate property/method tags in /wire/core/Page.php a couple months ago, and I expanded upon them. Do you think this is a good model to carry through in other core files? This is a good point as well. I want to mention though that "fuel" is more of a old and now redundant thing (for backwards compatibility with the original PW 2.0). It's now preferable to use the wire('...') function to access API variables (rather than $this->fuel()). Technically they achieve the exact same thing. But I like wire() because it works anywhere (template files, bootstrapped shell scripts, modules, core) ... code examples are portable no matter where they come from or are going. Whereas $this->fuel only translates to within 'Wire' derived classes. But I'm not planning on deprecating $this->fuel() either. I'm just avoiding it in my own code and examples (only new stuff) so as not to confuse people studying code. But perhaps there is some way I can signal that $this->fuel() is an alias of wire() with phpdoc, to better clarify it for people in an IDE. I think PSR-0 will take care of this one and I'm anxious to move forward with that but need to resolve some questions about how it will affect language translation.

Thanks Martijn, found it -- I'm adding both you and Raymond to it.

Raymond, I have posted an update that fixes this issue in the Form Builder Support forum. I'm not sure if you have access to that board because I don't see your name in the list. Was your order placed under a different name? Let me know and I can update or add to it in the fulfillment system which should correct your access, but just need to know which order to edit.

Thanks Raymond, I was able to reproduce that and am working on a fix now. Should have it within the hour.

I'm not really a fan of robots.txt for keeping bots out of URLs I'd like to keep confidential. Why? Because if someone wants to know where they can find the "interesting" URLs, they just have to take a look at your robots.txt. The meta noindex,nofollow at least doesn't broadcast the location of the page. So far my experience is that search engines that honor robots.txt also honor the noindex,nofollow meta tag.

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.