ryan

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?

TinyMCE can be maddening sometimes in this respect, as I've tried adding allowed attributes only to have TinyMCE refuse them for some reason or another. It's almost as if there are some other rules at play overriding user defined ones. However, if you set TinyMCE to allow everything then it usually works. The way you do that is to set your valid_elements to this: *[*] Not saying that's a good solution, but it works in a pinch and sometimes it's the only way I can get TinyMCE to cooperate.

Sounds like they could be Apache internal server errors. You might have to go to the Apache and PHP logs to see what's causing it. But in my experience, it's most often something in the .htaccess. When I run into an unexplained 500 apache error, I'll usually start commenting stuff out of the .htaccess file until it starts working, in order to isolate what the problematic directive is.

Interesting. I guess I'm not familiar with that Flickr BBCode. Can you post an example? I'm betting we can get Hanna code to make it happen.

This is an error MySQL would report if there was no "data1439" column present in the field_title table. I'm guessing that 1439 is the ID of your "default" language. There was a bug in PW related to this that I fixed recently (within the last 3 months I think). Double check that you are using PW 2.3. If you are already using it, you might try switching to the dev branch (at least to test) to see if that fixes it. Please let me know what you find.

I'm pretty sure that a Repeater can't be used for Inputfield forms outside of ProcessPageEdit. It's sufficiently complex enough, and tied into its storage engine (pages) that it can't be used for other forms. As a result, if you need something similar, you might have to bundle your own input type into an InputfieldMarkup or something.

That's true for a couple of those ID definitions (mainly 1 and 2), but for most it's ok to change them when/if you need to. The 404 page ID is one where there shouldn't be any problem with overriding it.

What version of ProcessWire? Check your /site/assets/logs/errors.txt and/or edit your /site/config.php and enable debug mode by setting the $config->debug=false; line to true. One of these should reveal the error, unless the internal server error is coming from Apache rather than PW.

Sorry, I should have realized and mentioned: the code I posted requires ProcessWire 2.3 and PHP 5.3+. Thanks to Soma, you've also got the version that is compatible with PW 2.2.9 and PHP 5.2, above.

I just used the Redirects module a couple weeks ago (for cmscritic.com) and imported a hundred or so redirects from a CSV. I haven't run into either of these issues. You might want to double check that the CSV you imported from has proper linebreaks?

Kent, that's correct–I'll update the readme file. The term "name" is set to the name of the Hanna code. This is provided to the PHP so that it can check the name of the code, just in case it needs it. Likewise, it's preferable not to use any API variable name for your attributes either.