ryan

I originally missed the issue with language switchers not working on the 404 page because all the instances where I'm using language switchers, I was only have it show the language switcher if the page was not the 404 page. The reasoning there is just that in my case, there wasn't much point in being able to show different language versions of a 404 page. If your situation is similar, I recommend simply not showing the language switcher when on a 404 page. Though if you want the switcher to redirect back to the homepage, that seems like another decent approach. But here's what I did: if($page->id != $config->http404PageID){ // render the language switcher }

ProcessPageAdd::getAllowedTemplates() now hookable on the dev branch.

If you are telling it to render using a specific template file, and that file doesn't exist, than an exception would be the right behavior. If there's a possibility the template might not be there, you should check yourself before asking it to render. Example: $file = 'markup/layouts/package.php'; if(is_file(wire('config')->paths->templates . $file)) { echo $package->render($file, array('layout' => 'package')); }

There is no FieldtypeName, and FieldtypeText is only going to use InputfieldText (it's not configurable for this particular fieldtype). So what I'd recommend doing us using the 'pattern' property of the field (which is supported by FieldtypeText) to require a name format: $field_templates->pattern = '^[-_.a-z0-9]+$'; If you want it to accept spaces too, then add a space immediately after the 0-9.

I'm using the default theme, so not positive what method it's using to show you 'latest updates'. But assuming it's showing pages with the most recent 'modified' date, chances are that some module hook somewhere updated that page. Either that, or it's limiting them to a specific time and you fell in that time one time and not another. This may be a question for that theme's thread.

That's essentially what I posted above, though in a different context (module config rather than ProcessPageEdit). If you wanted one in ProcessPageEdit, you'd probably want to create a new Fieldtype for it. Actually, just checked and it looks like Hani already has.

labelFieldName is specific to InputfieldPage. It identifies the field that you want to use as the selectable label. Typically this would be 'title', but for something that doesn't have a title 'path' would be a good choice.

The biggest issue that I can see here is that you don't have page numbers enabled for your template. ProcessWire putting in the "page=2" is a signal of that. So before you do anything else, go and enable page numbers by editing your 'search' template–you'll see the option to enable page numbers on the URLs tab. When it comes to dealing with your 'vendor' field, I recommend whitelisting it to a string in whatever format you want to extract it. For instance, maybe you want to use commas as a separator rather than pipes. You can whitelist it like this: $input->whitelist('vendor', implode(',', $vendors)); // if vendors is an array $input->whitelist('vendor', str_replace('|', ',', $vendors)); // if vendors is a PageArray Though you could certainly stick with "|" pipes if you preferred. But what I don't want to see you do is bundle that right from $input->get->vendor into a selector without validating it first. So switching to another separator makes that intention a little more clear. For instance, your form processor might capture and sanitize the vendor variable like this: if($input->get->vendor) { if(is_array($input->get->vendor)) { // array from form submission $dirty = $input->get->vendor; } else { // convert from your CSV string to array $dirty = explode(',', $input->get->vendor); } $vendor = array(); foreach($dirty as $id) $vendor[] = (int) $id; // sanitize to INTs $vendor = implode('|', $vendor); // convert to 123|456|789 string, ready for selector } else { $vendor = ''; }

The way you do it is to first add a new integer field to your 'brand' template. Call it something like 'num_products'. You might choose to make it hidden, so that it doesn't appear in the editor (if you prefer that). Next edit your /site/templates/admin.php and add this above the include() line that's already there: $pages->addHook('saveReady', null, 'updateBrandQuantities'); function updateBrandQuantities($event) { $page = $event->arguments(0); if($page->template == 'brand') { // a 'brand' page is being saved $page->num_products = wire('pages')->count("template=product, brands=$page"); } else if($page->template == 'product' && $page->isChanged('brands')) { // a 'product' page is being saved and 'brands' changed foreach($page->brands as $brand) $brand->save(); } } The trick is that if you already have a populated site, then you have to establish the quantities for the first time by saving all the 'brand' pages. You could temporarily add this code to one of your site's template files and view the page to populate them. After that, remove the code as it would no longer be needed. foreach($pages->find("template=brand") as $brand) { $brand->save(); }

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.