Soma

This works for me $this->pages->addHookAfter('deleted', $this, 'deleteUser'); public function deleteUser($event){ $page = $event->arguments(0); if($page->skip) return; // to prevent multiple calls when using Pages::trash(ed) $page->skip = true; if($page->template == 'student'){ $this->message("Page name in trash $page->name"); $name = str_replace("{$page->id}_", "", $page->name); // strip out the id_ in name $u = $this->users->get($name); if($u->id) { if($this->pages->delete($u, true)) { // maybe recursive in case user has children $this->message("deleted user $name"); } } else { $this->error("user $name not found"); } } } This same code also works with this code $this->pages->addHookAfter('delete', $this, 'deleteUser'); $this->pages->addHookAfter('trashed', $this, 'deleteUser'); $this->pages->addHookAfter('trash', $this, 'deleteUser'); Just depends what you need.

How have you noticed? What 404 page are we talking about? PW default 404 page? It correctly throws an 404 header. It will not (of course) if you access it directly via url then it will be a 200. A 404 in templates, you could write throw new Wire404Exception(); This will render the 404 page and send correct 404 header.

Ok as you said pages in the trash does have their name changed? Does $page->name really match the user page name? Can you get the user if you enter the name there hardcoded? $the_user = $this->users->get("name=hisname");

So going further good coding is not just assuming it will work, often it begins with always checking if you get what you need. if($p->id) { // do soemthing with $p } else { $this->error("Page not found"); } Will always make a huge difference in finding errors or prevent them.

I think it doesn't matter. The question is wether the page get's deleted or trashed (in backend?). In general, I can't stress enough on you guys here that coding is knowing how to debug and try out thing, print out vars, exit or die. I think you would easily find the problem. The more infos you have to more likely and easily you'll find the problem. No fear! Often with hooks it's good to exit("your var $page->name"); or use $this->message("your var $page->name"); so you can see the message and if the hook get's called and output some infos. Most often a NullPage means a get() or find() doesn't find a page and returns a NullPage, so further operations don't work.

I think you need to hook trash() and not delete. Deleting pages in the backed will trash them and not perm delete them.

pwired, you posted now half a dozen links to that webuilder. It's cool you found it and seem to like it but little annoying to have 3 continuous posts of you with the same links to their features list. Apart from that it's not an IDE but a code editor. I almost closed window after reading: "WeBuilder is a faster, smarter and more powerful all-in-one code editor for web developers. Clean interface, ..." I never got why these editors have so many buttons and interfaces (ugly)... then they even write something like: "No clutter WeBuilder is quick, clean and lightweight. It very powerful, yet not stuffed with useless buttons or panels." lol? Looking at their websites code, I think doesn't speak well for them and their editor. I'm so happy I don't have to use such editors and there's these wonderful new editors that focus on what's important. // personal rant over

Great job on this one! Impressed also on the screencast, very nice to listen to you. I'm just curious for now about caching html. Why didn't you use the MarkupCache feature of PW? Of course your technic using a text field is also nice.

findRandomTimed() returns an array not a single page.

Or use this script I created to create and send a zip to browser. https://gist.github.com/somatonic/6427247 /* creates a compressed zip file */ function create_zip($files = array(),$destination = '',$overwrite = false) { if(file_exists($destination) && !$overwrite) { return false; } if(is_array($files)) { foreach($files as $name => $file) { if(!file_exists($file)) unset($files[$name]); } } if(count($files)) { $zip = new ZipArchive(); if(!$zip->open($destination, $overwrite ? ZIPARCHIVE::OVERWRITE : ZIPARCHIVE::CREATE)) return false; foreach($files as $name => $file) { $zip->addFile($file,$name); } $zip->close(); return $destination; } else { return false; } } // get a language to export json files $lang = $languages->get("de"); $files_to_zip = array(); // "language_files" = file field on language page where json's are stored foreach($lang->language_files as $f){ $files_to_zip[$f->name] = $f->filename; } $zip = create_zip($files_to_zip, $config->paths->root . 'language_files_de.zip' ,true); if($zip) wireSendFile($zip); // send file to browser (/wire/core/functions.php) This would be put in a template file. Have fun. While doing this we might need a wireCreateZip() function in core as we also got a wireUnzipFile().

Look for id of the language page and look in the assets/files/id ... there you'll find the jsons.

Sound strange as I don't see what you can do with yii what you can't with PW. It a bit like using yii with laravel.

Good luck, we also have had projects in the past with lots of languages and en us version (not with PW) and it's a pain no matter what CMS. Often they don't really serve texts for each dialect specific, it's often just for a phone number or little text here and there. Annoying. Hard to decide what makes most sense without knowing the project in detail. Without thinking a lot maybe.. /en/page1/ /en/page2/ /es/page1/ /es/page2/ ..and have root home page urlSegments turned on. ..then construct your links /en-us/page1/ /en-us/page2/ /en-uk/page1/ /en-uk/page2/ /es/page1/ /es/page2/ if a url solves to a page that already exists PW will render the page itself, otherwise the path end up as urlsSegments in your home ( or urlSegmentsStr I think in 2.3.1 dev only) and in the home template have code to read urlsegments and load and render a specific page. /en-us/page1/ and /en-uk/page1/ mapping to /en/page1/ : if(count($input->urlSegments)){ // we have url segment(s) if($input->urlSegment1 == "en-us") { $input->setUrlSegment(1, "en"); $dialect = 'us'; } elseif($input->urlSegment1 == "en-uk"){ $input->setUrlSegment(1, "en"); $dialect = 'uk'; } $p = $pages->get("/".$input->urlSegmentStr."/"); // if url didn't resolve to a page show the 404 page if(!$p->id) throw new Wire404Exception(); // render the page and give it a $options['dialect'] echo $p->render(array('dialect' => $dialect)); } else { // output your home page ... } In page that are rendered this way will have the dialect set in $options['dialect'], which you could use to output different address or phone number. Maybe I'm missing something and written in the browser so take it with a grain of salt.

Works fine here echo $page->title; // meine seite echo ucwords($page->title); // Meine Seite Also ucwords isn't multibyte save. So special chars don't get uppercase.

To problem 2. After testing we found that in where the language suddenly changes from "fr" to "default" is where we in API modify a user (not current) and save it. Afterwards the $user->language is set to "default" of the current user. THe culprit seems to be that after $page->save() there's a uncacheAll called which cleans out the $user->language set on runtime. We have now a workaround to save language before to a var, and give it back to the $user after the save. But it looks like when saving a user in front-end the $user->language set by the language system is reset.

A co-worker is desperate building a front-end project tool with 3 languages. 1. Now there a problem with new users and roles etc, that are saved as pages. They only have a name field with non language page names as normal pages. Now creating a new user, the status for each langauge isn't set to 1. Means it's not active! Now if I query a user with its name it doesn't get found from a alternative language. When in default language (front-end) $users->get("xyz"); // returns user correct When in a alternative language $users->get("xyz"); // returns nothing 2. Sometimes the translation in the front-end using the PW translator sometimes doesn't output the correct language even though the $user->language is "fr" the output is in some part is the german (default) text. This happens a lot on after a form submission. It makes no sense and we are lost how to find the issue. After outputting the $user->language in various parts of the code where it happens, it suddenly is "default" instead of "fr". Any ideas what could cause it?

That function is now in core for use with WireArrays. This isn't only for pages. Just as an example with a stack of images: $fs = new WireArray(); $pa = $pages->find("template=image, image.count>0"); foreach($pa as $p){ $fs->add($p->image); } $f = $fs->findRandomTimed(1); echo $f->first

Why not wait for Ryan to comment your same question in that other thread? http://processwire.com/talk/topic/2067-repeaterpage-delete-bug-report/ http://processwire.com/talk/topic/3172-orphaned-repeater-data/ http://processwire.com/talk/topic/2304-deleting-pages-with-repeater-fields/ but it's hard to help when the questioner don't respond to question anymore and Ryan couldn't reproduce, and some threads seems hanging because maybe they also created yet another thread. The repeater page you see when creating a new page are the precreated repeaters that are yet not used but ready to add.

I'm not sure why you're asking because obviously you already got the solution answered yourself. RewriteCond %{HTTPS} off RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] just before the # RewriteCond %{HTTP_HOST} !^www\. [NC] # RewriteRule ^ http://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301] Or doesn't it work? Just remember to keep the htaccess updated in case PW changes it.

OK, .live() got remove in jquery 1.9, and PW is still using 1.8.3. http://api.jquery.com/live/

Thinking about that you seem to have your app mainly working under "/members/". Why not just add that? $pages->get("/members/")->get("id=1733"); $members = $pages->get("/members/"); $members->get("id=1322"); And you don't have to care about trash.

Yes it does work, as the I use the input names and in dimensions inputfield I set them to "fieldname_width, fieldname_height", so this seems to work fine.

Any selector added to the id=id will work except include=all. It doesn't really matter what as it will ignore anything in trash anyway. (1001 is in trash) "id=1001" // will return the page if exists, bypassing a find "search" "id=1001,status=" // will search and return the page if exists, except if in trash "id=1001,status>".Page::statusTrash // ditto, even though the status says only pages in trash "id=1001,parent=" // ditto "id=1001,template=" // ditto "id=1001,parent=7" // ditto "id=1001,has_parent!=7" // ditto As Ryan stated get and find searches will never return pages from the trash. As soon as there's another selector found, it will do a pagefinder search and exclude trash and others that are not accessible by the user. So apart from it doesn't matter you could add a: ",status<" . Page::statusTrash Instead of the variable to add to all those get(id), you could create a function to search for a id exluding trash. // at the beginning of you template output, or something like _init.php $pages->addHook("getPage", null, "getPageNotTrash"); function getPageNotTrash($event){ $id = (int) $event->arguments(0); $event->return = wire("pages")->get("id=$id,status<" . Page::statusTrash); } // in your templates use echo $pages->getPage(1733)->title . "<br>"; But I'm still with my code previous, to check for if the page is in trash and trow an error.

Ok I'm stupid, as I placed an exit in core to debug something... not my day I guess.

Something strange going on as suddenly the latest wire version stopped working at all, after switching back. I then put in again older version and it needed two refreshs to get it work again. After changing again to latest it again stopped working at all. I now dropped in a new copy of the latest wire folder from the repo and it works again, even in bootstrap. Hmm.