nickie

In functions, use wire('user')->languageor, in case of module files: $this->wire('user')->language

I would use some JS code that would add "placeholder" content to the inputfield elements (which would be easy, since they are all referenced by ID in the admin template) wherever I want default content. This way it would only be displayed if the field were empty, and shouldn't be particularly problematic from a security point of view either (I think...). Let me know if you want to see some example code.

Thanks for the suggestion and the link, Pete, so far our front-end search needs were limited to the title field, but this is going to change soon as lots of social features are being implemented, so I will definitely need to learn all about the cache fieldtype. enricob, the site is currently in open beta and lacking some functionality and server tuning we want to have in place before sharing (especially as an example of what PW can do). A lot of new features are still being implemented and hopefully the site should be well-tested and ready to showcase within about a month. I am eagerly looking forward to posting a case-study about it in the forums then, and will drop you a note as a heads up.

Hey there, I don't know which Admin theme you are using, but I think both Default and AdminThemeReno use the "ProcessPageList" module (in /wire/modules/Process/) to render the page tree on the "/admin/page" link. I checked the module settings and it doesn't have an option to select "show all subpages" (for good reason - there can be a lot of nesting or just a lot of children, which could slow down the render considerably or fail altogether), so some customization might be required in your case. I really like to root around in the module files, and found that in this module's "ProcessPageList.module" file an AJAX request is constructed to render the list, and the request includes which rootID to build the tree on (in this case it would be the homepage, so ID=1) and also includes whether/which IDs should be "open" - same as if you navigated to "/admin/page/?open=282" and it would show the whole page tree with all the parents of page ID 282 open and all its children visible. In the ProcessPageList.module file, this render function (in dev version) starts on #L117. You can see that the $openPageIDs array is defined from L122 to #L128: $openPageIDs = array(); if($this->openPage->id > 1) { $openPageIDs[] = $this->openPage->id; foreach($this->openPage->parents() as $parent) { if($parent->id > 1) $openPageIDs[] = $parent->id; } } (I'll assume a little familiarity with OO PHP, but if not there is no better place (IMHO) to learn that the module files.)As you can see above (and in the lines just following the above snippet), the openPagesID parameter in the initial request constructed in the .module file is an array, so we can actually just put in it all the children of the root page which have children, and it will execute the "open" request on each of those pages one-by-one. I tested the following solutions in AdminThemeReno (with PW 2.5.21 dev version) and it worked to open all the sub-page views one after another, so that in a couple of seconds you have the whole tree (subpages included) rendered. You can try out the one which works for your situation (and revert right back to the original in case of errors): Option 1: If you know that the nesting on your tree is only one level deep, it's pretty easy: $openPageIDs = array(); /**snippet to add:**/ // $this->openPage->id is a variable of the class instance indicated in the URL as ?open=IDnumber ($input->get->open's value), if it doesn't exist we use the root : foreach($this->pages->get($this->openPage->id ? $this->openPage->id : 1)->children as $child){ if($child->numChildren()) //if it has children, add it to the array of IDs to open: $openPageIDs[] = $child->id; } /**end snippet**/ if($this->openPage->id > 1) { $openPageIDs[] = $this->openPage->id; foreach($this->openPage->parents() as $parent) { if($parent->id > 1) $openPageIDs[] = $parent->id; } } The above might be enough for your case, especially if you have only one level deep nesting (only children of homepage have subchildren).Option 2: If you have a bit more nesting, here's a solution that works. Please beware that I'm not very good at OO PHP myself, and with a lot of children this might be pretty slow. Also, it uses a recursive function, and your PHP extensions might have a limit on how many nested calls are allowed (e.g xdebug allows 100 levels). Step 1. declare a protected variable for the whole class called $openAll (you can add it just after L26). Step 2. create a protected method for the class called getChildParents (or something less confusing): protected function getChildParents($id){ // pass the function ID of root/parent on which to check $p = $this->pages->get($id); foreach($p->children as $child){ if($child->numChildren()){ // if child has children, add it to the global variable $openAll: $this->openAll[] = $child->id; // call this function with child ID as parent ID: $this->getChildParents($child->id); } } } Step 3. Change the snippet I added in the first solution to the following: $openPageIDs = array(); /**snippet to add:**/ // instantiate the global variable as an empty array: $this->openAll = array(); // call the recursive function starting with the $input->get->open ID which will populate the array we just instantiated: $this->getChildParents($this->openPage->id ? $this->openPage->id : 1); // since openPageIDs array was empty to begin with, we can just copy our new array into it: if(count($this->openAll)) $openPageIDs = $this->openAll; /**end snippet **/ if($this->openPage->id > 1) { $openPageIDs[] = $this->openPage->id; foreach($this->openPage->parents() as $parent) { if($parent->id > 1) $openPageIDs[] = $parent->id; } } If any particular ID has a LOT of children but no subchildren, you can include a condition in the function to skip its checking.Option 3: Easiest option of all - if your client won't be creating new subnesting herself (adding children where none existed before), and if you already know which pages you want to open, you can skip all of the above and just instantiate $openPageIDs array to have a list of IDs you always want to open along with the homepage. In any case, it might take a second or two to have all of them render, so tell her to be patient. (PS: It's very possible there's an easier / less recursive way to do this in PW, in which case hopefully one of the experienced people will chime in and correct my method.) ETA: I changed the count selector to the built-in numChildren to check for children, which includes hidden children. You can also add the "include=all" condition on any of the ->children() or ->child() calls, especially if you are not seeing hidden/unpublished children where you want to see them. I do want to re-emphasize that this can become a memory intensive operation if applied to a site with many thousands of pages or many sublevels, but hope it helps in your case.

I am currently managing a PW site with 2 million+ pages. It's admirably fast, and much, much faster than any other CMS we tested. Searching is also ridiculously fast when done on single fields like title. (I also just did a test search using the page finder and it took < 4 seconds to find pages which had a particular field empty from a template which has 1.63 million pages.) The site doesn't deal with many image or file uploads (yet), but two optimizations I have applied so far are to 1) always, always use limits on using $pages->find(), and 2)to cache the sitemaps (which contain thousands of links each) using Procache(https://processwire.com/api/modules/procache/) Once you know where specifically your site is using the most resources, you can apply more selective caching / database optimizations. Thanks for starting this topic, I learned about pageFileExtendedPaths... there's always some cool feature I didn't know about and now must have!

Hey there, First, I think the field is "roles" not "role" - at least that's what my lister tells me (you can see the lister selector when debug mode is on)... anyway I don't think that's your main problem. I followed the exact same steps you did and the same thing happened to me - after I set a condition in inputfield dependency ("roles=38") for admin_theme field, which didn't work to hide the field - I removed the condition, and after that the field is not showing its options. So then I created two test fields (one integer and one Pagefield with radio selection for single Page only) and added it to user, then I followed the exact same steps (show only if "roles=38") - and it worked perfectly for both of them. Both fields show up in the edit-page of the users with role=38(superuser role in my case), but not in any of the others. So I'm thinking this may be a quirk of the admin_theme field. Ryan will probably take a look at it when he sees this, or you can post to github to get his attention if it's urgent.

I have seen that error when fieldtype doesn't match input or a required field is empty, but it generally informs me what field was the problem (with a big old red notice on top of the field too). So that's weird that you're not getting any description of the problem. If you haven't added any of your own fields to the user template and have checked/double-checked the input of every form, here is what I would do : 1. turn on debug in /site/config.php and see if it gives any extra information 2. If that fails, search the code to see where it outputs that error. (Only one place: https://github.com/ryancramerdesign/ProcessWire/blob/676458407bd530b69b50c6ef2f44cf16e4ef4449/wire/modules/Process/ProcessPageEdit/ProcessPageEdit.module#L211) Based on that it's safe to assume you have some formErrors. Look a few lines before that (L195), I would temporarily change $formErrors = 0; foreach($this->notices as $notice) { if($notice instanceof NoticeError) $formErrors++; }to $formErrors = 0; foreach($this->notices as $notice) { if($notice instanceof NoticeError) { $this->error('Notice: '.$notice); $formErrors++; } } That might give you a clue about the notice that is causing a formError. Once you get that info (or even if you don't), you should undo the changes you made to the module file. Anyway it's a hack, but it's how I sometimes investigate what is happening...

pages_id is not a column in pages, I think you are looking for 'id'. Results for query('SELECT COLUMN_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME='pages'): +-------------------+ | COLUMN_NAME | +-------------------+ | id | | parent_id | | templates_id | | name | | status | | modified | | modified_users_id | | created | | created_users_id | | sort | +-------------------+

Ryan, thanks for pointing me in the exact direction I needed to go! The PW version was not the issue, as I was using 2.5.21 dev. The file you linked to (Fields.php) was the exact source of the memory exhaustion, specifically on a line (caught in the trace too) inside the slow method: if($numPages <= 200 || $hasDeletePageField) { // not many pages to operate on, OR fieldtype has a custom deletePageField method, // so use verbose/slow method to delete the field from pages $items = $this->wire('pages')->find($selector); // << the problematic line, since I have 2.3million pages! //iterate through items etc } The test for the slower method was proving true because of $numPages, which is defined as $numPages = $this->getNumPages($field, array('template' => $template)); which calculates the number of pages which has the field set. So since the field was empty in all pages, numpages was turning out to be zero.I set the slow delete condition to 'false' temporarily, and was able to delete the field via admin in a heartbeat. Since the actual process of page-by-page field deletion doesn't make use of numPages at all, I'm thinking maybe it should be changed to include all pages of the template? Unless I'm missing some other use for it. In any case, thank you so much for the reply, sorted me right out.

Thanks for the SQL code, Marc. And your warning is well heeded - backup and Xdebug are in order. I haven't run into the error in other places yet, but you are right, it's foolish to wait for that to happen before I deal with it.

For relative URL, you can use: <a href="<?php echo $pages->get(23)->url;?>">Page with ID 23</a>If you want the full http URL, use ->httpUrl instead of ->url. Edited to add: Sorry, forgot to add the 's' to $pages - totally different variable

Just wanted to add that deleting the field via admin (with debug on) results in the same issue and similar stack trace. I submit at a URL like /admin/setup/template/removeFields?id=50&fields=119 (confirm delete and submit page) and then get stuck at /admin/setup/template/removeFields which shows the following: Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 72 bytes) in www/wire/core/PageFinder.php on line 307 Call Stack: 0.0000 249512 1. {main}() www/index.php:0 0.0708 4524720 2. ProcessPageView->execute() www/index.php:240 0.0708 4525072 3. Wire->__call() www/index.php:240 0.0708 4525072 4. Wire->runHooks() www/wire/core/Wire.php:320 0.0708 4527200 5. call_user_func_array:{www/wire/core/Wire.php:365}() www/wire/core/Wire.php:365 0.0708 4527536 6. ProcessPageView->___execute() www/wire/core/Wire.php:365 0.0841 4898216 7. Page->render() www/wire/modules/Process/ProcessPageView.module:172 0.0841 4898400 8. Wire->__call() www/wire/modules/Process/ProcessPageView.module:172 0.0841 4898400 9. Wire->runHooks() www/wire/core/Wire.php:320 0.0842 4903392 10. PageRender->renderPage() www/wire/core/Wire.php:387 0.0842 4903744 11. Wire->__call() www/wire/core/Wire.php:387 0.0842 4903744 12. Wire->runHooks() www/wire/core/Wire.php:320 0.0842 4905872 13. call_user_func_array:{www/wire/core/Wire.php:365}() www/wire/core/Wire.php:365 0.0842 4906208 14. PageRender->___renderPage() www/wire/core/Wire.php:365 0.0846 4947200 15. TemplateFile->render() www/wire/modules/PageRender.module:356 0.0846 4947384 16. Wire->__call() www/wire/modules/PageRender.module:356 0.0846 4947384 17. Wire->runHooks() www/wire/core/Wire.php:320 0.0846 4949512 18. call_user_func_array:{www/wire/core/Wire.php:365}() www/wire/core/Wire.php:365 0.0846 4949680 19. TemplateFile->___render() www/wire/core/Wire.php:365 0.0847 4974624 20. require('www/site/templates/admin.php') www/wire/core/TemplateFile.php:169 0.0848 4975272 21. require('www/wire/modules/AdminTheme/AdminThemeReno/controller.php') www/site/templates/admin.php:15 0.0848 4975824 22. require('www/wire/core/admin.php') www/wire/modules/AdminTheme/AdminThemeReno/controller.php:13 0.0874 5362888 23. ProcessController->execute() www/wire/core/admin.php:93 0.0874 5363072 24. Wire->__call() www/wire/core/admin.php:93 0.0874 5363072 25. Wire->runHooks() www/wire/core/Wire.php:320 0.0874 5365200 26. call_user_func_array:{www/wire/core/Wire.php:365}() www/wire/core/Wire.php:365 0.0875 5365368 27. ProcessController->___execute() www/wire/core/Wire.php:365 0.8661 5455992 28. ProcessTemplate->executeRemoveFields() www/wire/core/ProcessController.php:213 0.8667 5495960 29. Fieldgroup->save() www/wire/modules/Process/ProcessTemplate/ProcessTemplate.module:1977 0.8667 5496176 30. Fieldgroups->save() www/wire/core/Fieldgroup.php:318 0.8667 5496528 31. Wire->__call() www/wire/core/Fieldgroup.php:318 0.8667 5496528 32. Wire->runHooks() www/wire/core/Wire.php:320 0.8667 5498344 33. call_user_func_array:{www/wire/core/Wire.php:365}() www/wire/core/Wire.php:365 0.8667 5498680 34. Fieldgroups->___save() www/wire/core/Wire.php:365 0.8670 5503608 35. FieldtypeInteger->deleteTemplateField() www/wire/core/Fieldgroups.php:196 0.8670 5504048 36. Wire->__call() www/wire/core/Fieldgroups.php:196 0.8670 5504048 37. Wire->runHooks() www/wire/core/Wire.php:320 0.8670 5506184 38. call_user_func_array:{www/wire/core/Wire.php:365}() www/wire/core/Wire.php:365 0.8670 5506608 39. Fieldtype->___deleteTemplateField() www/wire/core/Wire.php:365 0.8670 5507040 40. Fields->deleteFieldDataByTemplate() www/wire/core/Fieldtype.php:878 0.8670 5507480 41. Wire->__call() www/wire/core/Fieldtype.php:878 0.8671 5507480 42. Wire->runHooks() www/wire/core/Wire.php:320 0.8671 5509312 43. call_user_func_array:{www/wire/core/Wire.php:365}() www/wire/core/Wire.php:365 0.8671 5509736 44. Fields->___deleteFieldDataByTemplate() www/wire/core/Wire.php:365 0.8891 5512848 45. Pages->find() www/wire/core/Fields.php:536 0.8891 5513200 46. Wire->__call() www/wire/core/Fields.php:536 0.8891 5513200 47. Wire->runHooks() www/wire/core/Wire.php:320 0.8892 5515064 48. call_user_func_array:{www/wire/core/Wire.php:365}() www/wire/core/Wire.php:365 0.8892 5515400 49. Pages->___find() www/wire/core/Wire.php:365 0.8895 5519328 50. PageFinder->find() www/wire/core/Pages.php:199 0.8895 5519768 51. Wire->__call() www/wire/core/Pages.php:199 0.8895 5519768 52. Wire->runHooks() www/wire/core/Wire.php:320 0.8895 5521584 53. call_user_func_array:{www/wire/core/Wire.php:365}() www/wire/core/Wire.php:365 0.8895 5522008 54. PageFinder->___find() www/wire/core/Wire.php:365 I thought maybe the issue is that there is no page with the data (database table of field I am trying to delete is empty) so maybe there is some circular reference or something (I heard this can cause memory exhaustion)... but setting a few pages with some arbitrary value for the field didn't make any difference.

kongondo, the code (for my delete.php template, which results in the memory exhaustion) is pretty much verbatim from your snippet in the thread I linked to above: https://processwire.com/talk/topic/7480-removing-a-field-from-database/?p=72039 if ($user->isSuperuser()) { //first remove the fields from 'user' template before deleting them. $t = $templates->get('user'); $fg = $t->fieldgroup; $fg->remove($fields->get('your_field')); $fg->save(); //delete the fields $f = $fields->get('your_field'); $fields->delete($f); }My 'your_field' is a plain integer field, and template ('user' in above code snippet) is the one with millions o' pages.Thanks for any insight you can provide.

Hi pwired, It's related to a question I posted a couple of months ago (https://processwire.com/talk/topic/8604-how-to-build-pw-site-on-top-of-existing-database-that-keeps-changing/)... it's a feed-reading application with social features and whatnots. The people I am working with (and me most of all) might out of our league here, but I kept pushing them to pick Processwire and boy am I glad I did! One of the important features is searching through the 2+million pages by title etc, and it is really fast. There are of course other options (Solr/ Redis/ ?) if it slows down in another few million pages, but right now it is performing admirably. As for this empty field - after posting the above question I did poke around in the database, and saw that actually the extra field is taking up only 2-3 rows (in different tables) and an empty table for itself, even though theoretically it is 'added' to millions of pages. Very cool, and I figured I won't sweat it at the moment. (I want to create and delete a test field from a different template first, just to make sure... but it's not going to affect performance until I do, which is a relief.) I guess the above question has more relevance as a memory leak question maybe. I don't really know how to figure those out, so I'll leave this here in hopes someone who knows how to read the trace can help me understand what exactly happened.

The field is empty, the template has over 2 million pages. So of course caution is necessary... I can't try anything too crazy. When I try to delete the field in admin area, as soon as I click on the confirmation checkbox and submit, it goes straightaway (fraction of a second) to a Bad Gateway 502 (nginx) error page. I also tried the API solution outlined by kongondo here: https://processwire.com/talk/topic/7480-removing-a-field-from-database/?p=72039 - it does not work, the script just stops running (again very quickly) at the save() part. Also tried deleting from the $fieldgroups api variable instead of from $templates. Same issue. Here is what I am getting from debug=true: Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 72 bytes) in /www/wire/core/PageFinder.php on line 306 Call Stack: 0.0000 242496 1. {main}()/www/index.php:0 0.0663 4512544 2. ProcessPageView->execute()/www/index.php:240 0.0663 4512896 3. Wire->__call()/www/index.php:240 0.0663 4512896 4. Wire->runHooks()/www/wire/core/Wire.php:320 0.0663 4515024 5. call_user_func_array:{www/wire/core/Wire.php:365}()/www/wire/core/Wire.php:365 0.0663 4515360 6. ProcessPageView->___execute()/www/wire/core/Wire.php:365 0.0721 4647600 7. Page->render()/www/wire/modules/Process/ProcessPageView.module:172 0.0721 4647784 8. Wire->__call()/www/wire/modules/Process/ProcessPageView.module:172 0.0721 4647784 9. Wire->runHooks()/www/wire/core/Wire.php:320 0.0722 4652776 10. PageRender->renderPage()/www/wire/core/Wire.php:387 0.0722 4653128 11. Wire->__call()/www/wire/core/Wire.php:387 0.0722 4653128 12. Wire->runHooks()/www/wire/core/Wire.php:320 0.0722 4655256 13. call_user_func_array:{www/wire/core/Wire.php:365}()/www/wire/core/Wire.php:365 0.0722 4655592 14. PageRender->___renderPage()/www/wire/core/Wire.php:365 0.0726 4696624 15. TemplateFile->render()/www/wire/modules/PageRender.module:356 0.0726 4696808 16. Wire->__call()/www/wire/modules/PageRender.module:356 0.0726 4696808 17. Wire->runHooks()/www/wire/core/Wire.php:320 0.0726 4698936 18. call_user_func_array:{www/wire/core/Wire.php:365}()/www/wire/core/Wire.php:365 0.0726 4699104 19. TemplateFile->___render()/www/wire/core/Wire.php:365 0.0727 4723816 20. require('/www/site/templates/delete.php')/www/wire/core/TemplateFile.php:169 0.0742 4726296 21. Fieldgroups->save()/www/site/templates/delete.php:14 0.0742 4726648 22. Wire->__call()/www/site/templates/delete.php:14 0.0742 4726648 23. Wire->runHooks()/www/wire/core/Wire.php:320 0.0742 4728464 24. call_user_func_array:{www/wire/core/Wire.php:365}()/www/wire/core/Wire.php:365 0.0742 4728800 25. Fieldgroups->___save()/www/wire/core/Wire.php:365 0.0745 4733760 26. FieldtypeInteger->deleteTemplateField()/www/wire/core/Fieldgroups.php:196 0.0745 4734200 27. Wire->__call()/www/wire/core/Fieldgroups.php:196 0.0745 4734200 28. Wire->runHooks()/www/wire/core/Wire.php:320 0.0745 4736336 29. call_user_func_array:{www/wire/core/Wire.php:365}()/www/wire/core/Wire.php:365 0.0745 4736760 30. Fieldtype->___deleteTemplateField()/www/wire/core/Wire.php:365 0.0745 4737192 31. Fields->deleteFieldDataByTemplate()/www/wire/core/Fieldtype.php:878 0.0745 4737632 32. Wire->__call()/www/wire/core/Fieldtype.php:878 0.0746 4737632 33. Wire->runHooks()/www/wire/core/Wire.php:320 0.0746 4739464 34. call_user_func_array:{www/wire/core/Wire.php:365}()/www/wire/core/Wire.php:365 0.0746 4739888 35. Fields->___deleteFieldDataByTemplate()/www/wire/core/Wire.php:365 0.0754 4743128 36. Pages->find()/www/wire/core/Fields.php:536 0.0754 4743480 37. Wire->__call()/www/wire/core/Fields.php:536 0.0754 4743480 38. Wire->runHooks()/www/wire/core/Wire.php:320 0.0754 4745344 39. call_user_func_array:{www/wire/core/Wire.php:365}()/www/wire/core/Wire.php:365 0.0754 4745680 40. Pages->___find()/www/wire/core/Wire.php:365 0.0758 4749608 41. PageFinder->find()/www/wire/core/Pages.php:199 0.0758 4750048 42. Wire->__call()/www/wire/core/Pages.php:199 0.0758 4750048 43. Wire->runHooks()/www/wire/core/Wire.php:320 0.0758 4751864 44. call_user_func_array:{www/wire/core/Wire.php:365}()/www/wire/core/Wire.php:365 0.0758 4752288 45. PageFinder->___find()/www/wire/core/Wire.php:365 Hope this is enough information for one of you seasoned folks to help me out.Thanks in advance!

The built-in comment field is probably even easier to handle, since all its saving functionality is built in. (https://processwire.com/api/fieldtypes/comments/) I was only mentioning "save" in the context of the first time a page or a comment is saved - if you do it via the API and all the fields required to publish the page are provided, the page IS published as well as saved then. So it would only happen that one time (e.g. in my code snippet in the earlier comment). So the forms for ticket creation and/or comment creation can have their 'action' attribute link to a page whose template processes the input va API. And yes, this would require some customization of the form, to send all the information you require (the other user's email address etc). I think either this way or hooking in the back-end with a module (and having both user emails as fields on the page in that case) might be the only two ways to achieve what you are needing, but I'll let others confirm that.

Hehe...who has rabies sometimes? Anyway, I'm not sure if you want the user to select all these additional settings for each field, or whether you want to choose it for them based on their answer to the first bit of each question? (Or is each question its own field ?? ) If it's the former (user should answer and select settings as well), maybe look at the table field? https://processwire.com/api/modules/profields/table/ So each row of the field would have 4 columns: a question, its answer, its display setting and email-inclusion setting. You would set the first field (question) and the user can provide the answer in the second, and they can also check/uncheck the third and fourth. I have tried using it once, and I think (I think) the way in which it is different from repeater is that you must specify a range of how many total rows you will need. I wanted to use it for comments so it didn't really work, but it might be just right for your case if you want a lot of input of different types but same pattern grouped together, and you know exactly how many. If you are currently creating new fields for every question, table field might help you eliminate it. Just use an additional column called "name" or something for each row, which will help you identify what your question was (for using it in the API). "children", "pets", "rabies" - just like fieldnames... If you want to show them specific fields based on their answer to "Do you have pets" etc... I'm not sure. Maybe inputfield dependencies? http://processwire.com/api/selectors/inputfield-dependencies/ Sorry, hope it helps..

Hard to know the exact use case you are talking about. I'm not really clear of the method you are using to create new comments on a page. But in case I understand your scenario and you don't want to hook into page->save via modules or something: You can create a separate template or two that just process forms for comment creation and ticket creation. So for example you have a user-facing page which has a form that submits to a hidden page called "/createticket/", and all the necessary data - the user-id of the selected user, the subject and message etc - are sent to the template. That template can create a new page for the user and while saving the page (using the API of course), do something like: $newpage = new Page(); ...//all the page related necessary data like template, title, parent and your own field data if($newpage->save()) { notifyByMail($user,$selected-user); } and have the notifyByMail function right there in that template file if you like, and if the mail is sent, you can redirect user to the newly created page with a success message.For comments too, if you are using Repeater fields to create comments on the page (e.g some $mypage), just send the input of the comment form to some other page whose template will process the input, create the repeater item, and on $mypage->save($comment) you can again hook in a notifyByMail function. (Not sure if that's how you save repeaters, I haven't used them in a while...) Basically it sounds like you only want to hook into the first page/repeater save, so it is best to do it when you are creating the page/repeater. Doing that via API makes it pretty easy.

horst, thank you for the reply! I have updated the module but the problem remains. It might be relevant that I have just changed servers - the cropimage upload used to work fine in the old server but in this new set up it's disappearing after reaching 100%. Since there are already several pages set up with the template, changing the field to tables or something else is not really an option. Any other ideas? I read other threads that suggested looking into the temporary upload directory config variable, so I added the following to the site/config.php file: $config->uploadTmpDir = dirname(__FILE__) . '/assets/uploads/'; Again that didn't change anything. As I mentioned, only the repeater cropimage is not saving, other file uploads and cropimages in non-repeater contexts are okay. EDITING TO ADD: Also after changing servers, the Database Backup module throws the following errors: >> Unable to create path for backups: ***/site/assets/backups/database/ >> Error: Call to a member function getAllTables() on a non-object (line 249 of ***/modules/ProcessDatabaseBackups/ProcessDatabaseBackups.module) I suspect this is the same issue... but I'm way out of my depth regarding what to do. Any help is deeply appreciated, thanks. EDIT2: File uploads in repeaters are just not working period, be it cropimage or regular image. :-/ ??

Title says it all... other image types are saving fine, including cropimages in other (non-repeater) contexts. However the cropimage in the repeater field uploads to 100%, then disappears. Please help!

Hi pwired - are you talking about PDOs or something else? How does PW api interact with database tables that haven't been created by it? In regular PHP terms? Yes Matthew, PW only. So I can interact via PW with database tables that have not been created by processwire as long as they are in the same database? Let me ask an easier (for me to understand) question: Say I have a database of products that is being auto-updated by some feeder in a given format. (product_id, product_name, price, source etc) I want to use some of the tables in this database to create PW pages for products, with fields that get their info from the database, and I also want to allow the PW-admin to make changes to these products, including their name and other information that has been extracted from the existing database. New items are also being added to the existing database every day (format same as before:product_id, product_name etc), and I would like these items to be added automatically to the PW site, without accidentally re-adding old items if their names have been changed. Is this possible? Would I need to be interacting directly with the database or via PW? (Gah, the fact that I don't even know the right questions to ask means I have a lot more studying yet to do. But I'll be back with more specific questions.)

Hello and thanks for any help you can provide! I know I'm in way over my head, but Processwire has me drunk on power. I know so little and yet so far I've been able to do pretty much everything I've wanted to, including all sorts of crazy admin features that until recently I'd thought were the sole purview of programming ninjas. Anyway on to my problem: thanks to PW I've picked up a lot of PHP, but I know next to nothing about MySQL. So you can assume utter-beginner level knowledge, but also full readiness to learn what needs to be learned to get the following done: I have an existing database that has lots of data I want to use to model PW pages on. How would I build a PW site using some of the fields/tables in this database? The PW database would need to change and re-model this data in various ways. This existing database also keeps changing. How can I stay in sync with the database, even while my database no longer looks like the existing database (cause my data changes too)? Where can I start learning about what I need to know to start doing this and slowly get on top of it? Please point me in the right direction to start investigating - modules, books, tutorials - any input is welcome and deeply appreciated. Thanks again.

Hi, This is my first post in these remarkable forums, I'm new to ProcessWire and I've had loads of questions but I just keep finding them already answered here! Except for this one - I bought a single-site license for a commercial module and when I try to install it on localhost it asks for the license key. Will I then be able to use this key on my live site as well, and also possibly on other localhost installations? Or will I have to import it in some way? Please let me know how the terms apply. Thank you, for all this.