kongondo

This is a multi-part question, so lets try to break it down. The normal workflow resembles the following: Data is requested on the client-side. In your case, this is via ajax. You'll need JavaScript code to send the ajax request The request is either sent to the current page or to a named url, i.e. you could have a dedicated page to receive the ajax request You process the ajax request by sanitizing and whitelisting the inputs You send a response back, normally as JSON, but could be xml, or whatever JavaScript code receives the response and manipulates the DOM (aka updating the page without refresh) How Tos How to Work with Ajax Driven Content: 1, 2 See #1 See input, sanitize, + search forums using these terms for more examples . See #1 See #1

Depends on what you mean by... What do you mean by 'doesn't publish'? Are you talking about the backend, in the PW admin? If yes, then the code has to go in a Hook, either in an autoload module or somewhere like admin.php

@MaryMatlow, Have a look at this, this and this post plus the ensuing discussions.

@jmn817 The answer is right there 2 posts above yours . If Center_Image is a single image field, then yes, you could have accessed it like you do. If it is a multi-image field, then you need to access it OR them using a different approach. Further reading.

Here's a complete example from the module Blog.

Let's throw in one more... How about using created_users_id/createdUser? It depends on your workflow though. Who creates the users? How are they created? Same for their respective pages. Doing it manually would mean your client heading over to settings tab when editing a page and changing the created user there (would have to be first enabled in the template). This may not be ideal. You could automatically change the created user ID using the API via an autoload module, but that depends on how the users are created since you want to synchronise the two actions. The advantage of this approach is that you can give your user pages whatever name you want to give them. You would use it like: if($page->createdUser->id != $user->id) {// @note: here you'd also need to add logic to let superadmin and some editor to have access :-) // don't allow access } // in a selector $userPage = $pages->get("template=members, created_users_id={$user->id}");

Hi @jmn817, Welcome to ProcessWire and the forums. I am assuming all these are separate pages ('folders)': politics, 2017, 01 and 17? In other words, your tree looks like/will look like? politics 2017 01// child of year 17// child of month 18 19 02 01 02 // etc 2018 If you 'day' pages are created chronologically, and not too much in advance (e.g. no day 21 before day 18), and if they have their own exclusive template, the following should achieve what you want I think. <ul id="trending"> <?php //$root = $pages->get("/politics/2017/01/17/"); // get the 'day' page that was created last. @note the -created. $root = $pages->get('template=name-of-day-template, sort=-created'); $children = $root->children("limit=5"); $children->prepend($root); foreach($children as $child) { echo "<li><a href='{$child->url}'>{$child->title}</a></li>"; } ?> </ul>

Why can't those code be combined? The example below works for me. public function init() { $this->pages->addHookBefore("saveReady", $this, "hookBefore"); } public function hookBefore(HookEvent $event) { // make sure we are on the right PARENT page $page = $event->arguments[0]; if($page->template !='some-template') return; // create new child page(s) $p = new Page(); $p->template = 'some-child-template'; $p->parent = $page; $p->title = 'New Child Page'; $p->save(); // set parent's number of children to its field 'number_of_children' // either method works. first one should be faster // @note: we DO NOT save the parent page here $page->number_of_children = $page->numChildren;// includes visible and non-visible children #$page->number_of_children = count($page->children); }

Maybe if we could see some code.... Edit Btw, will the number of children keep on increasing or are they created only once? Will the children decrease? i.e. get deleted at some point?

By blank page I take it you mean exactly that...nothing shows. You should be seeing an error about memory exhausted or Apache should crash. Why? Coz you are caught in an endless loop by the looks of the code. You save the number of children, and since that is also a save action, the hook fires again, and you end up in a perpetual loop. See illustration in your code below: $pages->addHookAfter("saved", function($event)// line #1 { $page = $event->arguments[0]; if ($page->template == 'events') { if (($page->numChildren) > 0) { $page->subdatesnumber = $page->numChildren; $page->save();// this will end up going back to line #1....and so on and on and on...... } } }); Try the suggestion here by @apeisa. Use addHookBefore and remove $page->save(); in you hook function.

What @LostKobrakai said. There are no hard and fast rules about such a situation. However, it is usually best to send a PR to the author of an existing module in case you believe your module offers some missing features, unless that existing module is not being actively maintained (in which case it could be forked and re-worked, anyway). The idea is not another WordPress please , if you get my drift. Quality over quantity is the mantra, However, there is no official position on this. The final decision is yours . Whatever you decide, thanks for your contribution. Looking forward to more .

Hi @creativejay, Thanks for your interest in Media Manager. Yes, that sort of update is supported. Change once, update everywhere - no need to re-link; (but you would have to update any image variations yourself, of course). Please see point #5 in this post. Thanks.

In respect of the demo itself, that's an interesting point you raise (since keywords do not necessarily have to be next to each other). In respect of your own use, you can change the search (selector) operator at this line in search.php. Here's a list of all the available operators. Not all of them will be relevant in this case. As per your suggestion, you want ~= Contains all the words.

It would be nice to see some screenshots, if at all possible

It will fit with anything. If you want it small, it will stay small. If you want a full e commerce solution, you can make it that. Shopping functionality can be added later or during, or before. It is not a pre-made solution. You get the same freedom as when designing your ProcessWire site. See more comments below. No. Padloper does not store credit card info. You would have to use one of the available payment gateways. Currently, there are two, PayPal and Stripe, both of which are available as free modules (by the same author of Padloper, @apeisa) The connection is seamless. With Padloper, you will have to be willing to 'construct' your shop so to speak. There is no ready-made template or anything like that. With this though, comes total freedom to code your shop just like any other ProcessWire template file since any page can be a product in Padloper. I suggest you read more on the product's website. There's also a public forum here where you can post further questions. I use Padloper myself here.

What situation? That 'how dare they charge a whopping $1 for music'? . Just kidding. Price here is immaterial. Whether $1 or $1000, the facts are: It will have to be paid via some means That means needs to be secure That means needs to be something your musician's fans have access to (e.g. PayPal, etc) Buyers will most likely expect to be able to download music they've bought right after payment has gone through The band will want to be able to track downloads, paid or unpaid Etc... I wouldn't reinvent the wheel with this one. Buying and selling will be taking place, period. I'd invest in Padloper ...(or if really, really, pushed, in some other ready made solution.).

More info here: http://processwire.com/api/ref/session/csrf/ In addition, excerpt from /wire/config.php. Emphasis here is on PW forms (on by default) /** * Protect CSRF? * * Enables CSRF (cross site request forgery) protection on all PW forms, recommended for improved security. * * @var bool * */ $config->protectCSRF = true;

Hi @MaryMatlow, Please read the docs, here (WIP), especially, this section, but for your specific question, this topic . Please note that some newer and amended methods have not yet found their way into the docs, e.g. the method renderRelatedPosts(). However, these are all in this (long, I know) thread but probably best to take a peek at MarkupBlog class itself for all render methods before we get the docs up to speed again.

For page creation, I meant that you should hook into the actual page creation process, or just after it. That means hooking into 'added'. I have tested (code below) and it works. Once the new tag has been created, we get the root parent of the 'post' being edited. If it is /blog/, we do nothing. Otherwise, we change its parent to the child of its root parent. Meaning, if editing /development/post1/, the root parent of the new tag will be /development/tags/new-tag/. But there's a catch.... Although the new tag(s) will be created fine, ProcessWire will not allow them to be listed as selectable pages since when setting up your page field, in order to be able to create 'new tags from field', as you know, you have to select both its parent and its template. The former is our problem. In my setup, the parent specified under 'Parent of selectable pages' is /blog/tags/. Since our new tag's parent in the case of development is /development/tags/ ProcessWire will throw an error 'Page 1234 is not valid for name_of_the_page_field'. So, it turns out our problem is not the actual page creation and contextual parent assignment, but the listing! That, from what I can tell, can't be circumvented via a Hook. Is there any reason you cannot use different templates and fields for /blog/post/ and /development/post/? Code to re-assign parent on new tag creation. Posted here in case anyone needs it. This was tested in a module. @note: the code could be optimised to only hook into the 'relevant pages'. public function init() { $this->pages->addHookAfter("added", $this, "changeTagParent"); } public function changeTagParent(HookEvent $event) { // get 'post' page being edited $process = $this->wire('process'); if($process && $process->className() != 'ProcessPageEdit') return; $pageEdit = $process->getPage(); // get the root parent of the 'post' being edited. we use it to determine whether to re-parent the 'new tag' $rootParent = $pageEdit->rootParent; // check root parent by path but can also check by ID, title, etc. if($rootParent->path == '/hook-tests-development/') { // newly created 'tag' page $page = $event->arguments[0]; // change the parent of the 'new tag' to /development/tags/ $page->parent = $rootParent->child(); $page->save(); } }

Aah, of course. I get you, my bad. Did you see my updates as well? About Hooking into page save in respect of contextual parent...

For listing/searching only, you don't need to hook into anything, mind. For creating new tag pages, what you will need to do, I think, is to hook into the page creation process. So, you could say, select the one parent in that setting, but in your Hook, you change that to the parent you want.

Regarding the listing, if you are willing to switch from Autocomplete to, say, ASM Select, you can easily allow tags to be contextually selected based on their grandparents (i.e. development and blog, respectively as rootParent) by making use of the setting "Custom PHP code to find selectable pages" (Input Tab when editing your page field). @note: The 'create under its own tag page' would NOT work in this case, though since that needs a named parent + template.

Which option didn't work for you? 1 or 2?

Consider these 2 options: https://processwire.com/api/modules/multi-site-support/ Option 1 would mean multiple databases. Option 2, single database is what you seem to be after. I use Option 1 for my own sites.

Just to clarify that RE in-memory selector, it actually also works for me. I was using the 'wrong' selector in my $pages->find() .