kongondo

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

Tested with 7 fields. When none was autojoined, worked as normal .When all autojoined, then there seems to be a limit. The more pages you select in the lower fields, the less fields are remembered in the upper 2-3 fields. Not sure if there are other confounding factors (e.g. templates). Tested using PW2.4 (one of the dev branch's, but not the very latest).

Btw, wouldn't $product->save throw an error?

@Can...looking forward to seeing your custom theme

I thought you said you could Google the forums with a single 'P'? ...just kidding...

Saml, Thanks for sharing! You can edit the thread title as the thread starter ...Just click on edit, and choose 'more reply options', then use 'full editor' or something along those lines... Edit: You have a typo on your website's menu "room and princing" For such a nice hotel, they should consider getting a corporate email address

You don't want to sanitize the password - you may end up changing someone's password! Instead, validate it against some rules you've set (most likely using Regex) - e.g. password length, allowed characters, etc....and alert user if it doesn't validate... Read more here: https://processwire.com/talk/topic/3543-register-users-and-add-page-same-as-username/?p=35151 https://processwire.com/talk/topic/5629-why-no-password-sanitization/

@Horst, I use a similar approach in Google. If I remember some keywords from the post, I add them to the query including the names of people I knew commented... I use the omni bar if I know I have bookmarked something - shows my bookmarks... or use the extension searchmarks.