ryan

Thanks for your review! Sounds like a great endorsement for this service. I hope to get the opportunity to try it sometime.

PW should support all current generation browsers: FF, Webkit, IE9 (and IE8 for the most part). I don't see any prob with supporting floatable fieldsets (I'd forgotten we didn't already), so will plan to make any needed updates to support that.

Output formatting always needs to be off when creating/saving pages. The beautification it does here is just the basic stuff that most of the time you don't want in URLs (like double dashes, adjacent punctuation, etc). Setting it twice is just an override for those rare cases when you really do want an unusual char combination.

In this case you would just be adding a new Page fieldtype (called something else) leaving the existing one as is. Then you'd edit your field (in setup > fields) and change the type to the new one you added.

Thanks for posting, this implementation looks pretty cool. I think Drupal lends itself particularly well to this sort of thing given that it's a markup generator where there are a lot of known factors both in structure and markup. What I usually think of as a disadvantage becomes an advantage with this sort of thing. It seems like a natural progression for Drupal as the admin side often is just an extension of the front-end already. I would also like to see something similar in ProcessWire at some point. But as a fun module useful for specific situations, not as a recommended way to edit most content. Inline editing is eye candy rather than something that's actually positive for the online experience. It really sends the wrong message when it comes to content portability and accessibility. Editors need to be focused on the content, not "this viewport." It goes against the nature of markup and regresses one back to thinking on print terms. I can see one of my clients trying to put a line break in the headline to make it look the way they want it, and then ending up with what looks like an error on mobile and feeds. That's just the tip of the iceberg. It also means you are no longer editing an an environment designed for editing. A place ideal for viewing and one ideal for editing may be very different places. But I like the potential of having a front-end editing capability for those times when the developer determines that the front-end is a good place to edit some things. Spark will be a good project to keep an eye on.

It sounds like the behavior you had before was with beautify turned off, and now it's turned on. Beautification includes removing adjacent punctuation characters, in addition to other things. You should be able to override that by setting it a second time (so that it knows you are serious). Try this: $p->name = $filename; $p->name = $filename;

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).