ryan

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.

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.