ryan

If there's a need for any method to be hookable, I can make it hookable. I didn't try to cover every possibility, instead preferring to make it easy to make hookable methods and them implementing them each time a need comes up. So if you want User::hasPermission to be hookable (for instance), just let me know and I'll make it hookable on the dev branch.

The strtotime call isn't technically necessary. You could also just do this: foreach($programs->find("program_start_date<04/01/$year") as $program) {

I'm not sure that I follow everything here. But if you are getting 1 fewer pages in the role_editable_pages than you expect, that seems to imply that something has removed a page from it at runtime. Looking at the above code, the only place that I see where a page is removed is here: $p = $parents->pop(); You might try commenting out that line to see if that's the culprit. Or if commenting it out will result in some kind of infinite loop, you could just echo the contents of it like $this->message("pop: $p"); ...I'd be curious if it's popping the /about/ page.

It sounds to me like no error is actually being generated by anything. You mentioned that you got this "Error retrieving Twitter status: 0". That indicates that oAuth didn't report any errors, since it's now reporting the status of the JSON decode. A status of 0 means json_decode() reported no errors. Unless you literally don't have any tweets on the timeline you are checking, chances are that we are getting tricked by the cache. Try disabling the cache by setting the # seconds to 0: $t->cacheSeconds = 0; Any change in the errors? -- edit: Ah, no tweets. Glad you found it.

The module actually only logs the errors in PW 2.3.1+ (current dev branch), as it's using the new $log API variable. So in 2.3.0. it's not going to be quite as clear. But try adding this line after your $t->render(): foreach(wire('notices') as $n) echo "<p>$n->text</p>"; See if it gives any more detail on the error? I've really tried to avoid throwing exceptions in this module (which would produce more obvious errors) so that some problem at Twitter doesn't interrupt your own site beyond the rendered markup from this module. And since I didn't know all the potential errors that tmhOAuth or Twitter might report, I didn't want to have it echoing any error messages that might potentially contain authentication related stuff.

It shouldn't matter if your site is multi-lingual or not. Though just out of curiosity, which method(s) of multi-language are you using? If you are right about "endless redirect" (as in a 301 or 302), most likely the issue is occurring somewhere before PW since there are no redirects in this template. Double check that your template is set to not have a trailing slash. Then, check your .htaccess file to make sure you don't have some directive in there that is enforcing trailing slashes.

Actually on the original update it said it was compatible with 2.2.9, as I thought it was at first. I realized later that day it wasn't and updated. So it's my mistake, not yours. You might need to enable debug mode. Also check here to make sure that your server is compatible with the requirements/dependencies listed: https://github.com/themattharris/tmhOAuth

That error translates to "Unexpected use of double colon". It's not something that should matter between PHP 5.2 and PHP 5.3, and that particular block of code hasn't changed. (though there have been other changes in Modules.php, and maybe this is a side effect?). That error can occur when there is a module file that is named differently from the class within it. This is why PW requires that a module class HelloWorld be contained in a file called HelloWorld.module. It's unusual for sure, I'm not sure what the issue could be. Do you know of any other differences in the server setup? Opcode cache or some other PHP stuff going on? It might be good for us to look at the phpinfo() output. Also, what 3rd party modules do you have installed? If you could PM me any relevant info to login via FTP, and to your PW admin, I should be able to debug this.

What version of PW? I was getting the same error recently, and not positive if the source is the same… but try out the latest dev branch, which has a fix for it.

I don't think anyone can answer that question except the person that put it there. But if there's something that says not to use it on a production site, and it's not necessary for the operation of the software, I would remove it. Though "don't use on a production site" is often just a kind way of saying "don't yell at me if something breaks."

Sounds like somebody made a mistake or typo in their filter. While ServInt uses the .net version (since they are a network provider) I think they use the .com for their own business email correspondence and such. I never remember which one to type in my browser.

If products are assigned directly to the brand or collection (rather than being assigned to the product) you could query it very easily… $brands = $pages->find("template=brand, products.count>0"); // $brands now contains all brands that have at least 1 product …but I'm assuming that each page under /catalog/men/suits/ has a "brands" and "collections" page reference field (rather than brands and collections having a "products" field). If that's the case, you can't query brands or collections directly since they don't have any field in their template that tracks what products they contain. You'd have to check them individually: $brands = array(); foreach($pages->get("/catalogue/brands/")->children() as $brand) { $numProducts = $pages->count("brands=$brand"); if($numProducts > 0) $brands[] = $brand; } // now the $brands array contains only brands that have products Another, potentially more efficient way (depending on quantities) would be to compile the brands from the products: $brands = new PageArray(); foreach($pages->find("template=product") as $product) { $brands->add($product->brands); } // $brands now contains all brands that have at least 1 product Lastly, I've solved this problem on the large scale by having an after(Pages::save) hook that calculates and stores (caches) the quantity directly in the brand, making it possible to query very easily. This is surprisingly easy to do, if you'd like more instructions let me know.

It seems like a generally good review, and very glad to see it. This is just the sort of exposure that really helps the project, so I'm very thankful for the review. Though it also seems like the review may have been based on a very brief experience with ProcessWire (maybe the demo?), as there's nothing to indicate the author(s) used it to develop anything, or know the system particularly well. I think this was primarily a good surface review (and nothing wrong with that). ProcessWire may be fine when you look at it on the surface, but it really shines when you actually use it, know it and develop in it. I think this is something most ProcessWire reviews miss. (CMSCritic.com is the only one I know that really gets it and has put ProcessWire through its paces). For example, the comment about global variables, among other things, seem a little out of left field to someone that knows ProcessWire well. I'm glad they thought our API was interesting, but I'm not sure they understood they understood the extent to which this is the driver of the system. The review stated the documentation was lacking, but I bet the author(s) didn't read the docs. People that do commit and read the docs tend to get a ton out of it. We probably wouldn't have nearly as active of a forum if everyone read the docs… for the record, I prefer having an active forum and getting people involved in the community, even if many questions can be answered in the docs. If we have a docs problem I think it's one of digestibility and structure rather than one of documentation scope. Outside of these things I think the author did a good job with the review and got a lot of points right. In fairness, if I was reviewing another CMS, it's unlikely I'd go develop a full site in it or read all the docs, etc. ProcessWire is a system where it's really about what's underneath rather than what's on the surface, and I think that's something very difficult to capture or communicate in review.

How about: $class = ($t->id == $page->belongs_to->id ? "active" : "none");

It was a bug, thanks for letting me know. It has been fixed on the dev branch.

I've pushed an update that fixes this issue: https://github.com/ryancramerdesign/ProcessWire/commit/9e1f46d3d1c69bebbd0415f58baad627a0d194d2 It was also a fairly simple matter to make it identify the language from the URL, when present. So I added that too. Meaning, if something about the URL points to a language (like /it/ at the beginning, for example) then it'll deliver the 404 in Italian rather than the default language.

I'll use an example of the Checkboxes inputfield, but it could also InputfieldAsmSelect or InputfieldSelectMultiple, etc. This is in the context of a ConfigurableModule's getModuleConfigInputfields() method, though it would be the same elsewhere. public static function getModuleConfigInputfields(array $data) { $form = new InputfieldWrapper(); if(!isset($data['templateIDs'])) $data['templateIDs'] = array(); $f = wire('modules')->get('InputfieldCheckboxes'); $f->attr('name', 'templateIDs'); foreach(wire('templates') as $template) { $f->addOption($template->id, $template->name); } $f->attr('value', $data['templateIDs']); $form->add($f); return $form; }

Hanna code probably wouldn't work here looking at the code. We could write a Hanna code to do it, but you'd have to specify the href and src differently, like this: [[flickr href=" " src="http://farm6.staticflickr.com/5506/9061328126_bac63857c2_z.jpg"]] It would be easy to make a Hanna code to do this, but of course you couldn't copy/paste a BBCode directly from Flickr using that method. So that kind of defeats the convenience purpose. You also probably don't want to apply the existing BBCode text formatter because it'll strip out your HTML. A new textformatter would be needed, that does nothing but convert BBCode without stripping HTML. Or, you could simply do this before outputting your $body field: $body = $page->body; if(strpos($body, '[url=') !== false) { $body = preg_replace( '{\[url=(.+?)\]\[img\](.+?)\[/img\]\[/url\]}', '<a href="$1"><img src="$2" alt=""></a>', $body); } echo $body; Not sure how we'd determine attributes like title, alt, width and height (or if you even need it). I'm guessing that would have to use an oEmbed service like the TextformatterVideoEmbed module does.

Thanks Valan, I got your message that the problem persists even on 2.3 dev. I will attempt to duplicate and let you know what I find.

Admittedly it's been awhile since I've tried styling an RSS feed, so don't consider myself an expert on that at the moment. I think the css property was added there at the request of someone else, because I've always used an XSL file linked in the RSS feed, in the past. But you can see if it's ending up in the feed just by viewing the source of the feed. Still I'm wondering if maybe you really want to use an XSL file rather than an CSS file? Example (though in PW1): RSS feed that links to XSL file: http://www.nanotechproject.org/news/rss/ XSL file links to CSS file: http://www.nanotechproject.org/process/templates/styles/rss_feed.xsl CSS file that styles feed: http://www.nanotechproject.org/process/templates/styles/rss_feed.css

The reason I don't do that is because variables aren't parsed within single quoted strings. Also, HTML and XHTML don't care whether you use single or double quotes, so long as you close the attribute with the same one you started it with. But if you want to use double quotes and have variables parsed, your best bet is to use the heredoc syntax: foreach($photos as $photo) echo <<< _OUT <ul> <li><a href="$photo->url">$photo->title</a></li> <li>Model: $photo->camera_model</li> <li>Resolution: $photo->photo_resolution</li> <li>Size: $photo->photo_size</li> </ul> _OUT; I don't use heredocs that often just because the closing identifier (like _OUT) can't be indented at all. So I find it interrupts the flow of code. But if I had a preference for double quoted HTML attributes, I'd probably use them all the time. I think that the approach you used is also good. For me personally, that's still a lot of extra punctuation and jumping in/out of PHP. But there's nothing wrong with it, it's good syntax (I sometimes use it too), and it's always good to use whatever you find the most easy to follow for a particular situation.

To me it sounds like our filename sanitizer gone astray. Like if it was performing a replacement of non-alphanumeric characters before doing an strtolower. I will try to duplicate here and let you know what I find.

I don't think there's anything wrong with your first code snippet. And I really don't think it's necessary to add those CR and TAB characters unless you need the HTML source to look that way. But if you are looking for ways to improve it, you might consider taking a route that reduces the punctuation a bit. For instance, this would produce the same output, but is a little easier to read and type: $photos = $page->children($selector); if(count($photos)) { foreach($photos as $photo) echo " <ul> <li><a href='$photo->url'>$photo->title</a></li> <li>Model: $photo->camera_model</li> <li>Resolution: $photo->photo_resolution</li> <li>Size: $photo->photo_size</li> </ul> "; } else { echo '<p>No photos found.</p>'; }

Thanks guys, these are good clear instructions. I will try to duplicate and fix here.

I'm confused, where are the .___ images coming from? That's not an extension that ProcessWire uses or would recognize. Allowed extensions for images are jpeg, jpg, png, or gif. What I'm not clear about is whether you are trying to import images with that ___ extension, or if it appears they are somehow getting generated by PW?