ryan

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.

That is actually better than what I was thinking, so we should go with that. I've plugged this into the 2.3 roadmap as a reminder, but will likely get it taken care of before then. http://processwire.com/about/roadmap/

I think we'll be able to build this as a module, which will solve the on/off thing. Just need to think more about how best to implement.

This is actually the expected behavior when you change the admin page's name because the system URLs are defined at bootstrap, so it doesn't immediately know that you changed the URL. Not ideal I know–I can think of a way to get around that, just haven't done it yet (changing the admin URL isn't something I do every day). But I think the issue mentioned in this thread is something completely different. I'm guessing it's got something to do with an apache setting that is removing trailing slashes from URLs, but need to find out more from Baki to be sure.

Yeah I agree, as long as there is a way to override the lock it should be good. i would guess that 50% of the time one sees this message, it would be because of a user that's not really editing the page but just left the window open to it. Though I suppose if we enforced a lock, people would be careful not to do that. The way we can check for an active session is just with some javascript that pings the server every 30 seconds or something like that. That way we can detect of a user still has an active session without relying on the last page request.

Thanks for finding that! Glad to finally know where all the facebook traffic was coming from. Their referrers aren't trackable, and searching facebook for 'processwire' turned up nothing, so it was a mystery before.

Not sure I understand?

I agree this should go in the near term roadmap. Though I'm thinking it would just be a warning rather than a lock, i.e. "Warning this page is currently being edited by Soma. You should avoid making edits until Soma is finished." The reason I think a warning rather than a lock is better is because someone may just leave their window open to a page, and we're pretty generous with long session timeouts.

It shouldn't matter where the sort is placed. I have a feeling there's a missing comma in your selector string, because that would make it appear that moving it to the end fixed it (since you don't need a comma at the end). One way to tell for sure would be to echo your selector string to see what is getting sent to PW: echo "$sort$limit$published$cats$id,published=1,pdate<=$today";

Thanks for the continued feedback. Given what I've learned here, I have updated our homepage <title> tag to: I don't think I can go any longer than that before Google will truncate it in the serps. But if anyone has any optimizations to suggest let me know. I think the first half is probably about right, but not sure how audience and keyword-relevant the second half is with "Strong API, Easy Admin (PHP 5)"... that's just my best guess.

Thanks, that's great. I'm actually not disappointed how well the server held up, given that it's a 'entry-level' vps with relatively low memory and resources. It was still serving pages at a load of 50+, though taking about 10-15 seconds to do so. As far as I know, the server never started refusing requests. Though I'm sure its slowness sent a lot of people away or left them with a bad impression. :-\ For starters, I'm going to install a PHP opcode cache (APC), as that should help.

Thanks, I will definitely appreciate your help here. It keeps a separate JSON translation file for each .php or .module file that is translated. Meaning, if you translated a ProcessPageEdit.module, then it would keep a languageName.ProcessPageEdit.json file containing all the translations for ProcessPageEdit (in 1 language). When you edit a page, all the translations for the current language in ProcessPageEdit get loaded. So it's not as memory efficient as loading each phrase translation at the time it's needed, but it is of course much faster. ProcessWire is not very 'wordy' so there isn't actually a lot of translation to keep in memory at any given time. But if memory becomes an issue, the plan is to provide an option for each translation that delegates it as 'always-load' or 'on-demand'. Currently all are 'always-load'. But 'on-demand' would be useful for things like error messages that rarely appear. Perhaps I'll provide this is an optional second boolean param to the $this->_() function that lets you mark a given phrase as 'on-demand' for such cases.

Your setup sounds just fine, though if we can't figure it out we may want to take a look at your phpinfo. If you have a URL with a "<?php phpinfo();" script, please email it to ryan at this domain name. Though first, lets take a look at this: When you see the 404 page, what is the exact URL remaining in your address bar? I think this might help us to determine what is happening. Lastly, can you post the resulting error in your /site/assets/logs/errors.txt , as it would help to get a look at that too.

Ah that makes sense, I guess that's called getting smashed. Despite that, the server is now on the mend (5min load down around 7 now). We just got hit with more traffic than the VPS could make processes for over 45 minutes or so. So I'm a little sad to know we probably turned some people away by being inaccessible. I'm setting up a mirror of the PW demo on processwire.org, though it's just a budget hosting account so not sure how much that'll help. I also need to get some more of the templates cached on processwire.com. I talked with the hosting company about upgrades, but they can't get in the upgrade fast enough to help today. So we'll just ride this one out and hopefully I'll be better prepared or the next time a spike like that occurs.

Hey guys, it looks like we're getting nailed with traffic today. Looks like I need to upgrade the server. I'm going to try and setup a mirror at processwire.org and see what the hosting company can do about upgrading the VPS. But wanted to provide advance warning that the server may go down today as the load just keeps rising (up above 50 right now). Looks like today will be our highest traffic day ever. Just hoping I can keep the server going.