ryan

Thanks Soma, I was able to reproduce it here too. Can you try out the fix I posted to the dev branch? You'll have to undo the page move you did before, and move it back again in order to get it to rebuild its index. 

Antti's right that it does sound like something going on at the server side (mod_security?). But I don't think there's any reason to use 2.2.9 anymore, so if it's as simple as using PW 2.3.0, why not just do that? However, don't be surprised if the issue turns up again, as mod_security can be a real pest when used with a CMS. 

Makes sense to me, I'll add it. Thanks. 

Matthew, I'm assuming this this error occurs after you perform $pages->find(), $pages->get(), or $page->children(), type call somewhere that contains a selector that looks like "title=some title, with a comma in it"? Wanze is right that you would want to use selectorValue on the "some title, with a comma in it" before bundling it into the selector. But if you are just creating pages, rather than querying pages for a title, then let me know. 

If your browser is displaying something after hitting reload, then you are dealing with a browser cache. Your server may have some aggressive cache settings by default (via Apache). Either that, or those machines are configured to go through a caching proxy server is aggressive. But if it's something you can control, you can try modify these settings in your .htaccess file. You might find this post helpful too. I don't think that ProCache was the problem here, so you should turn it back on and just configure it how you want it. You can have it clear the cache every time a page is saved, for instance. 

Because permission inheritance is determined at runtime. Two pages using the same template can inherit different permissions based on what templates their parent pages are using. To put it differently: when a page is using a template that does not define access, then that page is going to inherit the access from the nearest parent page using a template that does define access. As a result, if you only define access on your homepage template (which is the default setting) then those access settings are inherited throughout the entire site. But then if you had a page called /private-stuff/ that was using a template called "private", and that template defined access, then any pages below /private-stuff/ would inherit the access defined on the "private" template. The only exception would be if one of those pages used another template that itself defined a different access. 

You can just do: if($field->type == 'FieldtypeText'. But it looks like you are intending to operate on the 'title' field? In that case, I think what you really want is FieldtypePageTitle. 
The "+" won't concatenate strings in PHP. You want to use "." instead. 
With regard to everything else, it looks like you are on the right track. However, it might make more sense for you to just implement a Textformatter module instead, as this is exactly what they are designed for:
/site/modules/TextformatterOzwim.module
class TextformatterOwzim extends Textformatter {   public static function getModuleInfo() {     return array('title'=>'Ozwim','version'=>1,'summary'=>'Ozwim summary');    }   public function formatValue($page, $field, &$value) {     $value .= "- modified page title FTW";   } }  Once you've got that, install it and select it as the Textformatter for your page title field (or whatever field you want to apply it to). 

I figured it out. Since PageRender::renderPage is providing the rendered output in $event->return; rather than the function returning it (since it is actually a hook to a non-existent Page::render), then you have to do the same. As a result, this code in your before hook function should work:
$otherEvent = $event->arguments(0); // grab event provided to PageRender::renderPage $otherEvent->return = "<p>Hello World</p>"; // plug in our value $event->replace = true; // prevent PageRender::renderPage from being called

It sounds like something is wiping out the $user->language variable. Do you have any code that is setting $user->language in your site? Are there any other 3rd party modules installed that have to do with multi-language? If not, try replacing your /wire/modules/LanguageSupport/LanguageSupportPageNames.module file with the one attached--please let me know what you find?
LanguageSupportPageNames.module

We have append() for consistency with jQuery. I also like the team of prepend/append naming (it sure beat's PHP's unshift/push terminology). But I also think the term "add" is ultimately more friendly, especially when talking about adding an item to a group of items. As a result, I tend to use add() when adding items and append() when moving things around. Ultimately they do the same thing, but one may be more readable than the other depending on the context. Use whatever you prefer. 

I'm with kongondo, in that I'm confused and not sure I understand exactly what you are talking about. But I'll respond to the nuggets that I did understand.
Page status (hidden, locked, unpublished) does not inherit through the tree at all. A status on one page applies to that page only, and says nothing about it's children, etc.
That behavior is intentional and will not change. 
Your site will only display information that you specifically and intentionally output in your template files. If it is for something that you don't want to display, then it can be as simple as not having a template file at all for pages using a given template. If it's information that you only want to show to some users (like authenticated users with role "members", for instance), then you would perform a check before displaying your confidential information:
if($user->hasRole('members')) {   echo "<p>Launch codes: {$page->launch_codes}</p>"; } else {   echo "<p>Sorry, you do not have access to play this game.</p>"; }

Just add something like this to the top of your events index page. You could compartmentalize this into a LazyCron call, but for such a simple thing it's really not necessary. 
$events = $pages->find('parent=/events/, date<"-3 months"');  foreach($events as $event) {   $event->of(false);   $event->addStatus(Page::statusUnpublished);    $event->save();  }

Btw, when testing something out like this, always comment out the $event->save(); the first time and take a look at what pages get affected by echoing them rather than saving them, the first time around. i.e. 
// $event->save(); echo "<p>Unpublishing: $event->url</p>"; Once confirmed that it is behaving the way you want, then remove the echo and uncomment your save(); 

What version of ProcessWire are we talking about here? It sounds like 2.3 based on the file names mentioned, but want to double check. That seems pretty odd that PHP is writing sessions somewhere other than where specified. But ProcessWire uses PHP's native session features, so PHP is the one ultimately reading the session file rather than ProcessWire. Meaning, it's not possible for ProcessWire to read it from the wrong place, and I doubt PHP would read it from the wrong place. The only exception would be if you are using Database sessions, which is a module included with ProcessWire 2.3–did you install that by any chance? That would change the things that we need to look at. Also, just to rule out other possibilities, disable the "session fingerprinting" option in your /site/config.php and change the default session name from 'wire' to whatever PHP's default is:
$config->sessionName = session_name(); 

It sounds to me like an issue of case, somewhere. The skyscrapers profile field name is fieldset_meta_END (where END is uppercase). What is the case of the table in your MySQL db? I'm guessing it's got the uppercase END in it. You might try adjusting this setting in your /site/config.php to false, or rename the table in PhpMyAdmin to be all lowercase. 

Thanks jtborger, that makes sense to me. I'm updating it to this:
if(empty($options['baseUrl'])) {   $baseUrl = $this->page->url;   $urlSegmentStr = $this->input->urlSegmentStr;    if(strlen($urlSegmentStr)) $baseUrl = rtrim($baseUrl, '/') . "/$urlSegmentStr/";   $pager->setBaseUrl($baseUrl);  }

I would go ahead and create your new translation and post it as a follow-up reply to the existing one. If there's no response from the original authors (like pulling updates into the existing one) then we could just make your new version the current version linked by the directory. 
We don't usually break the API with new releases, though did have to in the 2.0 to 2.1 release. It may also happen in the 2.4 to 2.5 release when we switch to namespaces. There isn't any end-date to support of past versions. If some security issue turns up, It'll go into all current versions that we offer as downloads. For past versions that don't have active development branches, we would provide a file replacement or patch. To date, there have not been any security issues, so it's never been up to test. But it's always good to have a plan. 
We are very shy about changes that break things, so would version the API if behavior of some core functions changed from version to version. This is one reason why I think PW is a good/safe long term solution.
The problem that I've run into with WordPress and Drupal is that I can't leave old versions of them running because the site is only as secure as it is up-to-date. Old version of WordPress/Drupal = insecure (not to mention the plugins). An installation of one of these products becomes a permanent relationship with the client as you have to continually keep it up-to-date, in the same way you have to keep filling up your car with gas or it stops running. This is not the case with ProcessWire. I still have 7+ year old versions of ProcessWire (aka Dictator CMS and PW1) running sites perfectly fine. I could upgrade them, but there isn't really any need to unless the client needs some new feature present in a newer version of ProcessWire. Being able to install a software and trust that it's going to keep running on it's own for a decade or more, without my intervention, is worth a lot. 

That's essentially what I posted above, though in a different context (module config rather than ProcessPageEdit). If you wanted one in ProcessPageEdit, you'd probably want to create a new Fieldtype for it. Actually, just checked and it looks like Hani already has. 

You would want to include a "start=0" in a find() call that has a "limit=n" in its selector. This would be only for the results you don't want to paginate. I'm thinking this is the line: 
$posts = wire('pages')->find( "template=post, date>=$firstDay, date<=$lastDay, limit=$_limit, sort=-date, start=0" );

If I understand it correctly, it looks alright to me. We've done things like this before, connecting the user name with another page though rather than having a saperate "username" field, we just used the existing page "name" field to connect with the username. So that's the only thing I'd say, is to double check that you really need an extra "username" field, or if you can make use of the built-in name field to do all this. 

You can enable this option by editing your /site/config.php and setting $config->advanced=true; Next edit the template (Setup > Templates > edit) that you want to be able to change the createdUser. Click on the "system" tab (this is only visible in advanced mode). You'll see checkboxes for various options–check the appropriate one and save. Go back to your /site/config.php and remove the $config->advanced line you added earlier… as you don't usually want advanced mode on (some settings can be dangerous). But you should now have the ability to change the created user for pages using that template. 

Checkboxes can't be checked by default. This is to ensure you use scalable conventions in creating and maintaining your site. For instance, if you added a checkbox to an existing site that already had thousands of pages, and made the default "checked", then that would only apply to newly created pages from there … all of your thousands of existing pages would still be unchecked. Confusion, problems, and potentially a whole lot of work ensues. Whereas if you use checkboxes to toggle a non-default behavior, that is much more scalable and predictable. 

I think your files field may not be fully created yet. Go back to that field in Setup > Fields and hit save. Now try it again.
If you still get the error then go back to that field again, click on it's "details" tab and note the file extensions. Make sure that the file you are uploading is in the list of allowed extensions. Add more extensions as needed and save the field.

Okay I think I understand what you are saying. So you want to just load a fresh copy from the database, not keep an existing copy at some state in memory. Do this to load a fresh copy from the database:
wire('pages')->uncacheAll(); $oldPage = wire('pages')->get($page->id);

I'm responding from phone so keeping it short:

$image = $pages->get("template=page-headers, sort=random")->images->getRandom();