ryan

Great! Thanks for testing Diogo.

When it comes to markup render stuff that is needed throughout the site, I also use that hook/module method mentioned above, adding new hook methods as needed to Page and PageArray. $events = $pages->find("template=event, sort=-date, limit=3"); echo $events->renderEvents(); Either that, or I'll just put them in a separate file and call them up with functions: include("./tools.inc"); echo renderEvents($events); If i'm making a lot of repetitive $pages->find() calls, I might also add a new hook method to $pages to serve as a filter so that I could do this: $events = $pages->events("limit=3"); I think that inheritance isn't ideal if all you need is to add some new methods to a class. While it works, it's adding another level of complexity, so I prefer to plug-in to things where possible, rather than extend them through inheritance. But what works for one doesn't necessarily work for all, and people have different preferences and ways of achieving things, so I would stick with whatever makes the most sense for your project. The inheritance of Page that you see in PW's core (like User, Permission, etc.) is more about having a separate type for typecasting purposes, than it is for extending functionality of Page. Though in PW's case, it does both. But if I didn't need separate typecasting (for argument type hints and such) then I might have utilized hooks for these instead. It was also a way to keep the system consistent with PW 2.0, which had User, Permission, Role classes that weren't Page objects. By making the new classes extend Page, it was a way to avoid potentially breaking older code that expected those types. As for implications, stuff that is in 'Advanced' mode is there because I don't really know the full implications. So if you find everything works, I think you are good. But the only implication I would be worried about is just what happens during upgrades and whether they are more likely to affect the approach you are using. I can't say for certain, as I don't totally understand the approach, but if it works now, it's more likely to continue working than not. That being said, the further you go in using a different approach from others, the more difficult it may be to troubleshoot when something doesn't work. Using an MVC approach with PW also doesn't need to be complex. If you think of your template files as PHP controllers, your $page(s) as your model, and use the TemplateFile class to render your views, you have an easy to use and implement MVC setup. There are applications where I like to use this approach. But for most web sites I find it more convenient and maintainable to use templates, modules and includes in a more traditional way. There are times when layers on top of markup makes things better, and there are times when it makes it worse.

You don't have to use strtotime() or mkdtime() to build a timestamp if you don't want to. (you used to have to back in older versions though). You can use any date string recognized by strtotime, i.e. here's an example that loads all pages for a year specified in the URL segment: $year = (int) $input->urlSegment1; $blog = $page->children("date>=$year-01-01, date<=$year-12-31");

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.