kongondo

In that case, one way is to only allow them to delete the pages that they have created. I'll let others more knowledgeable chime in here The property $page->createdUser will get you the user In a selector you can search using created_users_id

If many users can be assigned the role frontend_editor, then it means you need to go further in your checks. Is there a maximum number of pages each user can create? Is there a limit to the number of users? Answers to these questions will help determine the approach needed to control access - e.g. for a site with 100K users, controlling access by giving them individual templates may not be very workable.... Just loud musings here..

I am not touching this with a 10-foot pole!!! Seems so addictive...

Good for? Why add another language on top of an already existing capable language (PHP?)...Yes, I know I used MODx and its templating language and loved it..but that was before I decided to take the plunge and learn PHP.......Anyway, this is like mermite...some people love smarty and similar while others don't. I like Ryan's summary here: http://processwire.com/api/why-php-syntax/. If you know PHP I suggest to forget template engines like smarty. They are just another layer of complexity you don't need...

@Jeff, Here the critical point is to check if the user has the right permissions. There are various ways of controlling access in PW, e.g. using permissions and roles at user level, at template level, and with some modules, at page level. For now, Google this and have read: "permission delete site:processwire.com" then let's talk...I need to run

OK...here is an example (rough-ish...and maybe even ugly code...) but it should give you an idea... //was a delete request sent... if ($input->post->delete) { //this will be in the form of delete=xxxx where xxxx is the page ID. Check in Firebug $deletePage = $input->post->delete; $id = (int) $deletePage;//sanitize post value to integer $p = $pages->get($id);//get this one page whose ID was sent over using its delete button $title = $p->title; $p->trash();//as a backup in the interim, we trash the page instead of deleting it. echo '<p>The page ' . $title . ' was successfully deleted</p>';//there are better ways to check! } else { //list of pages - this is only an example...modify to return your particular user's pages! $out = '<form action="./" method="post"><ol>';//this form posts to self foreach ($page->children('limit=10') as $child) { $out .= '<li>' . $child->title . '<button type="submit" name="delete" value="' . $child->id . '">delete</button></li>'; } $out .= '</ol></form>'; echo $out; } There are better ways to catch errors and check if this page was actually deleted. Here also we haven't checked if this user has permission to actually delete this page....but this should get you on your way...

Show us your code

You will get better answers but here are some examples...All these assume these code is being called in another page other than the one you are after...(pages..) $city = $pages->get("template=city, title=Doha");//get one specific city $cities = $pages->get("template=cities, title=Cities")->children("limit=10");//get 10 of all cities $cities = $pages->get("/path/to/cities/page/")->children("limit=10");//get 10 of all cities If you are able to follow, have a look at the code in the Blog Profile (maybe even the Skyscrapers profile)

@Jeff, No worries. ProcessWire has the API to create the markup that you see in modules or the admin (e.g. buttons, collapsible panels etc.) Whilst you can use some of these in the frontend as well, it is probably an overkill to recreate the delete button for your frontend needs using PW API. You don't need anything fancy; just create a normal button using HTML (either <input type="submit"> or <button></button>. The important things here are the name and value of the button, maybe an ID as well. This is normal HTML stuff. You can then style it (copy the PW CSS basically) to fit in with the rest of the PW page edit style...If you need more info let us know . When a HTML button is pressed (within a form), it will send it's name (e.g. name="delete") and the names and values of other relevant input types within than form, e.g. text fields, etc. In this case, since you want to delete the page, you are not interested in all that other information. What you want is the ID of the page that you want to delete. When requesting the page to be edited in the frontend (I don't know how you are doing it, Fredi? Custom form?). The id of that page is stored somewhere. Either in the URL...e.g. my-cool-page?id=2345 or it is stored probably in some hidden field. What you want is that ID. Use Dev tools in Chrome or similar to study how the delete button is structured. There is no magic really but I appreciate this might be difficult for a beginner. The other issue you will find if you read up on the subject of forms is whether values are sent via get or post. Using PW $input->get or $input->post covers both scenarios respectively. http://processwire.com/api/variables/input/ If using get to store the ID, the id is the id=2345 in my example above. $input->get->id will get you the 2345... Sorry, I realise I might have confused rather than informed but hope this helps Edited for mistake: the value of the page being edited is not the value of the submit button ...

What version of PW? In PW 2.4 admin themes are now modules and need to be installed as per normal modules... http://processwire.com/about/news/introducing-processwire-2.4/ https://processwire.com/talk/topic/4650-new-processwire-admin-theme-on-dev-branch/page-18#entry53671

Friendly advice Jeff...posting the same question in different boards won't give you quicker answers ...One version should be enough .... Back to your question, see my suggestions in your other post. I also think that at this point your are not asking the more important question. Whilst the issue of whether to use a button or a input checkbox is a valid one, that's not the pressing question. Whichever way you want to signal the users intent (programmatically), at the end of the day, it's just an input in a form sent via a post. The more important questions are how do I safely capture what has been sent by the user (whether it's a button press, or a checkbox, etc.) and what do I do with that input? The answers to these questions are all here in the forums (IIRC, I have pointed you to some of them ). Check out $input and $sanitizer in the API docs and forums. I'd also suggest that you Google and thoroughly read about 'capturing, validating and processing form input php'. It will help you immensely rather than copy pasting code ....As to how best to signal the users intent? I would probably use a button clearly labelled delete this page! Oh, I forgot in the other post, how do you know what page the user wants to delete? At the very minimum, you must capture the ID of the page being edited....

Jeff, the answer to your questions entails several parts; vxda has pointed you to one part. What's he's shown you is the API to unpublish/publish a page. You will need that when it comes to processing the programmatic request of a user to delete, Here's the parts as I see them 1. Is the user logged in? 2. Do they have the right to edit this page? 3. User clicks button to delete or publish/unpublish - this sends a $post request 4. Check and sanitize the $post request 5. Does this user have permission to delete this page? - this is an added safety net 6. If yes, delete the page and let user know [success or failure] Btw, remember delete and trash are different things in PW.... Gotta run...meanwhile, Google the forums about these suggested topics (I could have missed something...)

Adrian, I think Andre wants the date when the field (not the page) was added or modified. So, when was 'headline' added, for instance . The page could change subsequent times before and after, but he wants the time for this one particular field. I don't think this is possible out of the box?

A text field? Why are you checking it with 1 then? ....I haven't read you code properly but I suggest you use checkbox instead if all you want is to toggle true (==1) or false (==0) for user activation. So, if a user registers, use the API to set the value of the checkbox to 1 [checked]. If not, the checkbox remains un-ticked. For reference, in case you want to check if a text field has content just do something similar to: if($page->nameOfTextfield)//do something.[this is just an example saying if there's content in this field...] There are other ways as well, including using PHP's empty method....

What is this user_activation? A checkbox field? Some other type of field? Maybe also a case of this?

I think TinyMCE eats <div>; IIRC...not sure; I rarely use it...but maybe that can be overridden.....But, whether it does this or not, please, please, do not add/edit your markup structure inside rich text editors. You will get grief all day long . Things like divs ideally belong to your template files....and if you must, in a normal text area field....Having said that.... 1) - Have a look at the module called Hanna 2) - Only read your post quickly but there are various approaches. Those blocks could be pages, for instance...Alternatively, a simply foreach loop can be used to output the services markup of all listed services....+ Google the PW forums with keyword 'blocks' In PW getResources (and many other equivalent MODx snippets) are inbuilt - in this case $page, $pages...powerful and more efficient...

Thanks for prompt response Adrian. Haven't thought much about best approach but for now I would err on the side of caution. Alternative 1: Don't delete anything with other non-empty fields (other than name and title). However, the explanation you have on your post above should be included somewhere in the Warning. Maybe better.... Alternative 2: An extension of Alternative 1 (some Warning notice) + to skip only the problematic child pages, i.e. the operations should continue for child pages with empty fields but skipped over for those with content. Then, capture the titles of the problematic ones and display a separate single error message alongside the success message: "could not bulk/edit a, b, c, d, e, f, g, x, z, because...blah, blah" (up to a point, otherwise string can be very long!). This way, the user is not too disappointed. The current all or nothing can be frustrating if you've spent a while setting things up [but did not check for non-empty fields first] . Unless I am missing something and Alternative 2 is the current behaviour? Cheers

Aaah...Alternatively, reminds me of this thread https://processwire.com/talk/topic/3865-image-tags/ See Soma's solution (and comments) on that thread.... Something like this.. $images = $pages->get('/photos/')->children("image.tags=featured"); @Macrura, Thanks for the pointers!

Adrian, Thanks for this! Just finished testing...two things: Not sure if possible: Would it be possible, somehow to display names of child pages alongside their titles? This is helpful when 'overwrite names' is not checked; new pages are created with similar titles but different names. However, all the user sees are similar titles. Not a big issue since names are visible on hover of the titles of children pages above (i.e. the PW list of children/subpages). I have been getting this error: You cannot bulk edit these child pages, because at least one page has a field which is not empty. Try the edit option, or delete existing child pages first. in Create/Overwrite mode. Does this mean child pages fields have to be empty before they can be overwritten? Thanks again for the module! Great to see that it respects the template family settings

Not sure if this topic would help? https://processwire.com/talk/topic/417-extending-image-field/

In NP++: 'Save As', then select 'All Types(*)'. Yes, you need to make sure extension .module is there.. When viewing the file in NP++, also good to select 'Language' -> PHP

Aah...I was hoping it wasn't that....hooks are not my thing! (yet)...not sure how to add it... As for preferences, say, I have a module called 'accounts'. I don't want the user to feel like they are leaving this module's environment when adding an account (behind the scenes this is a page, of course). I want to provide a seamless experience to the user. I have about three choices to provide this sort of experience. One, include a form with inputfields matching the 'account' page's template and via post, use these to create the new 'account' page. Two, I can have a 'add a new page' open in a modal. Three, I can have the PageAdd module's form 'embedded' within my module to provide the seamless experience . Ta!

Reopening this one.... @Pete, I have tried to use the code you posted.... public function executeAdd() { $addForm = $this->modules->ProcessPageAdd; $addForm->parent_id = your_parent_page_id; return $addForm->execute(); } ...to load the PageAdd form within a module. The PageAdd form loads fine but the page does not save - nothing, no errors - but the page values are sent (including template ID). Google hasn't been helpful. I am also having one of those days when I can't see the wood for the trees . What am I failing to add? Ta!

Not hard, but you need to know what you are doing . Changes will be required in both modules - FieldtypeEvents.module and InputfieldEvents.module. Changes needed in the former are slightly more tricky since Fieldtypes describe and create database schemas. Looking at the code, currently the field 'data' that is required by all Fieldtypes is currently being used to store the values of the 'date' field as a unix time stamp. This would probably have to move to another column in the database, e.g. 'date' so that 'data' can instead hold the id of the selected page in your page field type. Changes to the latter are relatively easier. You would need to add a column to the events HTML table. You could then use the API to add, for example, a select field: $f = $this->modules->get('InputfieldSelect'); //more field properties as required... $opts = wire('pages')->find('template=hosts'); foreach($opts as $opt) { $f->addOption($opt->id, $opt->title); } From here it is just a matter of $f->render() in the table column you added (the <td>), to get something like this:

Yes....changes will not occur automatically. The new Admin theme is a module. An installation is required. If you have a new admin theme that is a module, it goes to /site/modules/ as usual. Of course, you cannot install the same (meaning same Class) module twice, so cannot just copy and install the admin theme. Have a look at this: https://processwire.com/talk/topic/3584-better-image-management-better-integration-with-wysiwyg/?p=60625