ryan

ggtr1138–thanks for the feedback and welcome to the forums!

It seems like we've got good ideas and momentum here and I'm very enthusiastic about getting this setup. I need to focus on getting the multi language features finalized first, but would like to start working on this afterwards while it's still fresh on everyone's mind.

I agree! Thanks everyone for all the great feedback! When other people read these reviews, they are very likely to give ProcessWire a try too, so it really makes a difference. Thanks again for taking the time to write these reviews.

In this case you are modifying content at runtime to change it before it's output. You could setup something in your header include (if you using one) to take care of all your fields at once. Or you could create a Textformatter module to do it for you. This one would be particularly simple: /site/modules/TextformatterResponsiveImages.module <?php class TextformatterResponsiveImages extends Textformatter { public static function getModuleInfo() { return array( 'title' => "Responsive Images", 'version' => 100, 'summary' => "Remove the width tags from images so they can be responsive." ); } public function format(&$str) { $str = preg_replace('/ (width|height)=.\d+./', '', $str); } } Place in /site/modules/, install it, and then select it for any of your fields where you want it to apply.

Sorry about that Digitex, I should have thought to update that stuff before, so thank you for letting me know. I have added an Upgrading section to the README file, and have also updated this upgrade thread: http://processwire.com/talk/index.php/topic,58.0.html Did you come across any other places I might have missed? Thanks, Ryan

I'm back at the computer and looking at hooks. I think that Page::render is still a good way to go. The only thing you need to consider here is that it's possible for it to be called more than once during a request. But that only happens if the API is being used to render the output of other pages too. I do that sometimes... for instance my 'ad' template contains the logic to select an ad and renders all the markup needed to display an ad, so main template calls $ad->render() to output the ad in the sidebar. So if you want a hook that's guaranteed to only be called once without you having to check anything, then you can hook into one of these: ProcessPageView::execute – $page will be available in an 'after' hook. This hook also returns the same rendered output that Page::render does (in $event->return) except that it only does it for the actual page that was requested. ProcessPageView::finished – called when the request is finished and output has been sent. This is a good place to put time-expensive operations, as it doesn't hold up the request. Also, I just added committed another… Your question got me thinking that we don't yet have the perfect hook for this. Ideally, we need the opposite of a finished() hook–something that can only be called once and is the first thing called when $this->page is ready to be used. Using a before(Page::render) hook is roughly the same, except that is can potentially be called more than once in a request. So I've just added this hook in the latest commit: ProcessPageView::ready – called when the $page API var is ready and before the page's output is rendered. You'd use this in the same place that you would use a before(Page::render) hook, except that this one is guaranteed to only be called for the $page that initiated the request.

Sounds great, can't wait to see what you are working on with this. I also did some PW work for a few hours this weekend, continued progress on the multi language stuff.

I wouldn't worry about overhead there. The only overhead comes from what happens in the hook, so if you are just doing a simple check before deciding whether to execute something in your hook you should be good. If you are processing forms, you could always scan that there is a post request, or some post var present before adding the hook. When I'm back at the computer tmrw I'll see if there is a better hook to use, but I think what you've got sounds good so far.

If its an autoload module Page actually isn't ready at init() because otherwise hooks couldn't catch page/field load events if it was. So at init you may want to hook Page::render or there are lots of other options too. Tell me more about your need here and I should be able to suggest a good one to hook.

I think that both WordPress and Joomla are only configured with one rich text (HTML) field per entry, by default. ProcessWire is different in this respect in that it's built around all custom fields and you may have as many or few of them as you want. PW's default profile is using the rich text editor for both the body and sidebar fields, so when both were populated with HTML, that's what was triggering it.

I agree, it is worth asking. But I also think that a hosting environment with such tight mod_security rules is a CMS-unfriendly environment (for any CMS). It looks to me like in this particular case, Baki could probably get around this one by just limiting each template to having only a single TinyMCE field, and using Markdown for any other fields that need any kind of formatting (given that HTML won't be allowed except in POST field). But personally I would consider looking at alternate hosting providers... there are so many, and it's not really worth jumping through a lot of hoops to get around overly aggressive mod_security settings. I also worry about hosting environments that have this kind of setup because I think these strict rules are sometimes in lieu of real managed security.

Good ideas Diogo! This really may be a feasible way to accomplish this type of field without major changes underneath, while also enabling any existing field to be repeatable without consideration from the fieldtype/inputfield. Or to word it differently, a simpler approach that is more powerful than the alternative. I am enthusiastic about this approach… it's something we should continue thinking and talking about.

I haven't actually tried to import users yet. But it should be possible. Go ahead and add the 'title' field to your user template and populate it with something (email address?) to see if that makes the import happy. I'll plain to make the import a little smarter in this regard on the next update.

PW still needs to support the PHP 5.2 branch, so we're not using namespaces yet, and I don't think that CI is either. As a result, I'm betting there's at least a chance that PW and CI would have a namespace conflict. include('./pw/index.php'); It's possible that CI may chdir somewhere else, so just as a test, you may want to put in an absolute path to PW. Given that the wire() function apparently isn't even defined, it makes me think that PW hasn't even had a chance to load yet.

I agree–I think that the thread linked to by diogo is exactly it. Please let us know what you find.

Thanks I received your email and logged in and was able to reproduce the issue you mentioned. I think I also have a better understanding of what is going on. Though it is rather bizarre. Try editing your homepage. You should be able to save it now. Then try going down to the 'sidebar' field, and type "<p>" tags around the the last line. Then hit save. Notice you now get a 404. It appears we are running up against a strange filter (mod_security or something with suhosin)? It is behaving with this rule set: There may be more factors to the rule, but that's it as best as I can tell. Note that you can reproduce this issue on any other page by applying that rule to any other page. I turned your sidebar field into a regular textarea just to make it easier to test. Go and type "<p>test</p>" in the sidebar field on any page, hit enter twice, and type it again, then save. You'll trigger the filter and get the 404. To test that the server really was wiping out the GET/POST vars, I tried changing your 404 page to use the Admin template, which shows debugging info. Then I saved the homepage. See the attached screenshot which shows the POST vars in the 404 page–there are none. Yet my HTTP header log shows all the vars that were POSTed and no redirects. Meaning, it appears something at the server is wiping out the vars before ProcessWire even loads, which is why it's giving a 404. Pretty bizarre. I think we're hitting up against a bad mod_security rule or some other server-side "security" filter that is getting triggered by the presence of some HTML combinations in a POST request. Another indication is that the server handles most requests pretty quickly, but as soon as a POST request has any kind of HTML in it, the POST request becomes unusually slow… as if the server is loading some other software to analyze the request before letting it go through. I believe your webhost may have made a mistake in whatever security measures they've put in place to cause this.

I usually use something recursive as a simple solution if having to deal with unknown levels. I think in this case it might also help to see the full scope of results you are trying to achieve, whether visually or in markup form. But I also think the solution you posted most recently seems reasonable and good, if that achieves what you are trying to do. I thought it was interesting how you are limiting the nav to certain templates. I usually use the hidden status on a page to direct whether it should appear in that type of navigation or not. But what you are doing gives a different type of control by delegating it to the output generation, and the template, rather than the page. Nothing wrong with that, I just hadn't tried that myself yet. Oops I meant for that to be wire('page'), though passing it in the function as an argument like you did is just as good.

I'll focus on your simple example because I was able to understand that one better. The most obvious way to simplify this would be to avoid repeating the same code by bundling it into a function. <?php function renderPageList($children) { $out = "<ul>"; foreach($children as $child) { $class = $child === $page ? 'class="active"' : ''; $out .= "\n<li><a href='{$child->url}' $class>{$child->title}</a></li>"; } return $out . "</ul>"; } if(count($page->parents) == 3 && $page->numChildren > 0) echo renderPageList($page->children); if(count($page->parents) > 3) echo renderPageList($page->parent->children);

Thanks I received your phpinfo and have reviewed it. It looks good to me, though there are two things there that I've not tested on my own before. That is eaccelerator and suhosin. A search for these on google reveals that there are apparently a few rare conflicts with other CMSs, so it's possible there's something there. Though I think both eaccelerator and suhosin are relatively common in commercial hosting environments so if that's the issue, it's more likely to be a particular setting in the extension rather than than the extension itself. However, I think there's only a 25% chance that either of these are the issue. If you are seeing a ProcessWire 404 page (as opposed to an Apache one), then it's PW that's still handling the request. Since there's not a clear answer yet, would it be possible for you to create an account for me in your ProcessWire installation? I would like to login and reproduce it myself while watching the request headers to see if there is anything unusual I can spot. Even better would be if I could get ssh or ftp access to make and test debug edits to track down exactly what's happening–that would be a sure way to tell. But let me know what works for you. Thanks, Ryan

This need has come up a couple times and I agree about the value of automatically keeping a history of such things for redirects. I will eventually make a module to do this if someone else doesn't beat me to it.

We'll definitely be adding more validation rules for existing fieldtypes and this is something I've been doing incrementally and regularly. The integer fieldtype used to have min/max range options in PW1, and they'll be coming back in PW2. You may already see that some fieldtypes and inputfields carry more validation rules than others. I also think it would be good for me to get a few starting-point examples of fieldtypes/inputfields going to show you guys how simple it is to make your own too. For instance, if I need a field that has specific requirements for input, I take the route of copying one of the existing ones into /site/modules/, renaming it and modifying it to do what I need. It's easy, but not described anywhere so I'll work on a tutorial here soon.

This should work: $page->body = preg_replace('/ (width|height)=.\d+./', '', $page->body); I just kept it simple since I don't think there are any other tags with width/height attributes that PW's TinyMCE would use.

Actually I thought it deserved to be posted twice.

Regarding the tweet, I appreciate the enthusiasm for PW, but I have nothing but respect for MODx and think that as a project they are a good role model and excellent software. But everyone is looking for something different in a CMS, and if there were one 'best' platform, then there wouldn't be so many CMSs out there.

It looks like they finally posted all of your reviews at opensourcecms--great reviews!! Thanks for this.