ryan

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.

Not sure I understand the question. What BBCode from Flickr?

You would want to include a "start=0" in a find() call that has a "limit=n" in its selector. This would be only for the results you don't want to paginate. I'm thinking this is the line: $posts = wire('pages')->find( "template=post, date>=$firstDay, date<=$lastDay, limit=$_limit, sort=-date, start=0" );

This capability is actually built into FormBuilder. When editing your form, go to the "settings" menu and check the box for "Preset field values from GET variables". Then on your page that has the form, just specify the GET variable you want to populate in the URL: /path/to/form/page/?subject=subject1 When you view the form (embedded with option A or B) the value will be pre-selected.

What about dropzone or one of these other ones Kongondo posted in the other thread? http://processwire.com/talk/topic/3761-dropzonejs-and-file-uploads/?p=36705

Just want to add that another benefit of taking the JS approach is that the pages could still be cached by PW's template cache or ProCache, etc.

You can, but you should tell ProCache the names of your GET parameters so that it won't attempt to cache those pages. You can do this in the ProCache settings on the bypass tab. See attached screenshot. The default setting is "*" which means that GET requests with variables aren't ever cached, regardless of the name. This is a good setting to keep if you don't want to think about what the GET variable names might be.