ryan

Repeaters should be okay with putting repeater B inside repeater A. But if you are putting repeater A inside repeater A… all bets are off. We'll have to add some extra checking for the folks that need the infinite recursive depth repeater features in their site.

These are floated blocks rather than a table, so the height of one doesn't affect the others. Though I wish it did. I probably wouldn't be able to sleep at night if I was using a table for layout here. Perhaps we can use a little JS to make them consistent in height when in the same row. Though, it's a bit of a questionable thing to do because fields aren't fixed height and may adjust dynamically as needed (like multi page reference inputs for instance).

I might be misunderstanding, but you should only see the context select when editing a field directly from Setup > Fields > Field. That context box is hidden when editing through a modal window (via Setup > Templates > Template > Click Field). Can you post a screenshot?

I updated the version to the latest a few months ago. I guess they are doing a good job of making regular updates to TinyMCE. I don't think we can update every time they release a new version just because everything has to inevitably be tested and re-tested every time we upgrade something like that. But I will plan to pull in the latest version when I bring in Soma's Bramus updates into the core (next week or two).

If you don't need to use LanguageSupport for actual regional languages, I think it would be fine to use it. It's been kept intentionally a bit abstract in that 'languages' can mean anything that localizes text. While we think of that as being to a person and their language, there's certainly no reason why you couldn't also look at that as localization to a device. I think you might also find the code internationalization convenient. However, it's good to consider what Soma said too as there are certainly some simple routes you can take that don't involve using LanguageSupport. And the concern with LanguageSupport is that you might use that to serve alternate versions of content at the same URL, which might not be beneficial to your search accessibility (Google, etc.). So if you do use LanguageSupport, you'd just want to activate the language based on hostname or something (i.e. m.domain.com vs. www.domain.com).

I can duplicate too. Though taking a closer look, I don't see an obvious reason or fix for this. I think it just gets down into the DOM manipulation done by tabs and the effect on events. I'm going to have to come back to this one, so have added an issue report at GitHub.

You can hook in before or after any method that starts with 3 underscores, like: ___methodName(). For more about this take a look at the Helloworld.module file included in the PW installation (/site/modules/Helloworld.module). Antti can probably advise better than me as to if or what methods in the shopping cart are intended to be hooked. But to answer your question I think we'd need to know more about specifically what you are trying to do in terms of output?

I think that the basic profile that is included with ProcessWire is probably the best example. Install that, and then copy a few of your other HTML files into the same root directory you've installed ProcessWire in. Those HTML files will still be accessible when accessed in the URL. So if you are putting part of your site in PW and the other part not, then it's just a matter of linking the two (by way of <a href=...>, etc.)

The file would still get passed through the server, though it sounds like it wouldn't go beyond PHP's temporary dir (and whatever holding areas are used by the SMTP server). I would be very surprised if phpmailer wasn't sanitizing for header injection since it's asking you to set things like 'From' and 'FromName' separately, rather than as a string of headers as with PHP's mail(). If it were going through PHP's mail(), we'd want to sanitize it like this: // validate email $fromEmail = $sanitizer->email($input->post->email); $subject = "Agent signup from website"; $body = "Your email body here"; if($fromEmail) { // makes sure it's 1 line (no CR/LF), max 50 chars and no tags $fromName = $sanitizer->text($input->post->name, array('maxLength' => 50)); // The sanitizer->text may be enough, but we'll go further here just to be safe... // remove any chars that aren't word characters, dash, digit, apostrophe, period or space $fromName = preg_replace('/[^-\w\d.\' ]/', ' ', $fromName); $headers = "From: $fromName <$fromEmail>"; } else $headers = ''; // send message mail($toEmail, $subject, $body, $headers);

While I know UTF-8 is possible in the query string of URLs, I had thought that domains/paths in URLs were limited to a subset of ascii characters (at least if we're trying to be standards compliant). I could be wrong about that, but honestly have not seen UTF-8 domains/paths before. (Or if I have, I didn't recognize it as that). Do you know of another open source CMS that supports this? I could take a closer look to see what's involved in the implementation and security of that, but would like to have other examples as this is something I'd not heard of before. Regarding Google and prioritization, is there any research/documentation that supports the theory that it prioritizes sites using UTF-8 in URLs? I guess that would surprise me, but I always have an open mind. You've got me curious.

echo "<ul>"; foreach($pages->get("/students/")->children) as $gender) { echo "<li><a href='{$gender->url}'>{$gender->title}</a><ul>"; // Male or Female foreach($gender->children as $student) { echo "<li><a href='{$student->url}'>{$student->title}</a></li>"; // Peter, Anna, etc. } echo "</ul></li>"; } echo "</ul>";

Welcome to the forums Barry. I don't think the CSV importer could be used with the repeater field type. Too many components to put together in making that one work through a simple CSV importer. I think you'd be better off using the API on that one. See here for repeater API usage (bottom of page).

Aggregate answer: Usage is optional. I look forward to installing this one.

A module doesn't necessarily need it's own directory, you could just put it in /site/modules/. But for modules that have more than one file, it's good to put them in their own directory. The directory should be of the same name as the module. However, there are cases where you might have multiple related modules go together (like the LanguageSupport modules), so PW will let you have a dir one depth that doesn't match the module name. In that case, it's good to name it with the primary module name (with LanguageSupport again being a good example of this). The modules in /wire/modules/ also use this quite a bit for grouping, as there are dirs for Process, Fieldtype, Inputfield, etc. You can do this for 1-level but not 2. The point of this is to place some limits on the directory parser to keep things fast. While it's not good to place them there, if you are aware of it and can respond properly during upgrades, I can't think of any reason why 3rd party modules wouldn't work from /wire/modules/. It seems like it should be okay. PW does keep a cache of module locations, so if it's one you had moved, that might have caused the error. But I can't think of anything else without seeing the actual error message. There aren't any real technical differences between /wire/modules/ and /site/modules/.

Thanks for testing this guys. I was able to reproduce it, though only on non-ready repeater pages (i.e. those that say "this will become editable after you save"). I've committed a fix to the source. I was wondering if you could grab it and let me know if it also resolves the issue on your end? Thanks, Ryan

I think that anything that enables an anonymous user to upload a file to a web server is a security concern and needs to be monitored closely. Disclaimer out of the way, your approach seems reasonable at first glance. At least, nothing jumps out at me initially, though I'm assuming that PHPMailer prevents header injection and does some of it's own validation. Also, in your foreach($form) where you generate the message, you may want to limit the length of both the $key and the $value that get added to the message body. For instance: $value = substr($value, 0, 255); to limit the max length to 255 characters. In addition to validating the uploaded file's 'type', you might also want to sanitize/validate the filename, and also ensure it actually ends with the expected extension (png).

Since the structure is already there, you probably want to use that structure and you won't need to worry about sort order at all, since the sort order is implicit in the structure. I'll adapt MadeMyDay's good example towards the structure from your screenshot. This may not be exactly what you are trying to achieve, but maybe it's close. But the point I'm trying to get across is just that it's better to use this structure for retrieving pages when your output results need it. It's also more efficient to use the structure rather than issuing separate find() queries to pluck stuff out of it arbitrarily. $issues = $pages->get("/journal/")->children(); foreach($issues as $issue) { echo $issue->title . '<br />'; $articles = $issue->children(); foreach($articles as $article) { echo ' - ' . $article->title . '<br />'; } }

Welcome to the forums CNSKnight. Also wanted to add that the most common way to get to that context is not actually from that drop-down, but from the actual template editor. You can click any field name in your template and it'll pop open a modal window where you can adjust the context.

You can have as much or as little of your site in ProcessWire as you want. ProcessWire will run alongside static HTML sites or sites running in other applications. As for access control, you can define access per-template. So if you want the client only updating the photo gallery page, you would only give them access to edit/create pages using your photo-gallery template.

Okay I think this is fixed now. Please try the latest commit and let me know if this resolves the issue on your end too? Thanks, Ryan

Thanks Soma, I can duplicate this. I will hunt it down.

So far I'm confused on this one. When you import fields, it's not getting involved in anything with access control. Repeater pages are also inaccessible to guest either way. They are only accessible via the page they originate from. What you describe sounds like a bug in there somewhere, but so far I can't consciously connect the result with the identified cause. I'll experiment. If anyone else experiences a similar result please let me know.

Mike, what you are trying to do sounds feasible and interesting. How far along with this are you and do you have any specific questions thus far? I'm not familiar with OpenCart, so would probably need to see your Inputfield code for context with any questions too.

Hani, this looks like a good and well thought out solution. Thanks for posting. I can't think of any immediate issues here, so if it seems to be working well in your case, I think you should be good. The only thing I might suggest is copying it to a separate module in /site/modules/InputfieldPageCustom.module or something like that, so that you have a separate module that can be easily carried through version changes. If you do that, remember to update the class name too. It would also enable you to more easily share the module with others that had a similar need.

Thanks, I will make the same change in the core, replacing the second 'true' param with 'Sanitizer::translate' in the setupNew() function. The translate option was added to the sanitizer pretty recently.