adrian

@horst - what do you think - does the use of the new sort() method in a Pages::saved hook (like my example above) make this module obsolete or is there another scenario I am not thinking of?

Yeah, I agree that it sounds like it should take care of it (and it appears to work just fine), but I guess I am wondering what the point of this is: // re-build sort values for children of $page, removing duplicates and gaps $pages->sort($page, true); Why would there be duplicates/gaps in the first place if the main sort() method works as expected? Maybe it's to clean things up if you did some manual changes? I am really not sure, but it seems like it shouldn't be necessary.

Based on the suggestion by @abdus, put this in your ready.php file: $this->addHookAfter("Pages::saved", function($event) { $this->pages->sort($event->arguments[0], 0); }); Note that $event->arguments[0] returns the page that was just saved. Perhaps it would be a good idea to resort all other children too - have a read more about this here: https://processwire.com/api/ref/pages/sort/ I think in this use case you'd actually want to use the parent of the saved page so that all child pages are sorted. I honestly have played around with this, so not sure if it matters or not.

Just echo $q where you want it: echo "Search results for $q";

$q contains the search term: https://github.com/processwire/processwire/blob/57b297fd1d828961b20ef29782012f75957d6886/site-beginner/templates/search.php#L20

Hi Ivan - without seeing the form code I don't really have any suggestions at the moment. Any chance the site is accessible to me to take a look?

@Peter Knight - where have you been?

Hey @Macrura - not much help I know, but I thought I should mention that I have one site hosted with Site5 and haven't had any problems like this. PS - nice "Tracy Settings" link

It should be easy to modify it so that if a template (defined by the user in the module settings) already exists to use it. If you send a PR directly to the main repo (Nicos), I can merge it for you.

Hi @quickjeff - did you set the template details on the config page of the MigratorWordpress module? It looks like even though it should use the template you defined, it will use "Basic Blog Page" as the label for the template - see here: https://github.com/adrianbj/MigratorWordpress/blob/fa8c54485f230db39c7fb5f5a42c6f1b5a3d27a9/MigratorWordpress.module#L279 Maybe it's not possible to use existing templates with the MigratorWordpress module - I need to check more thoroughly to confirm. If that's the case, it should be an easy fix though.

Thanks again @RDC - I am wondering if perhaps you'd consider submitting a PR to the Flourish guys - seems like it would be a good change for all their users. Once it is in their repo, I'd be happy to include the updated version in this module.

Hi @RDC - thanks for the update. I just took a look at the Flourish lib's github page and it looks like there is now a PHP 7 branch so maybe there is life in the project. I know you aren't using PHP 7, but I would still be curious if this new version works for you. You can grab the required flourish files here: https://github.com/flourishlib/flourish-classes/tree/php7-compat-plus-misc-fixes Please let me know how that goes.

Would mind posting an issue on Github about the two issues noted above so we know that Ryan will see it? Thank you!

Glad it worked for you Remember that $field->name is going to refer to things like "body", "headline", etc so it's actually calling: $item->body which returns the value of the body field. The use of $item->fields is like $page->fields which is mentioned in the docs and cheatsheet. Shameless plug, but I really find the Console panel in Tracy Debugger an incredibly useful tool - it lets you try code and dump objects and arrays in a nicely formatted way - it really helps the learning process.

I think perhaps I am not understanding what you are looking for, but does this suit your needs? foreach($page->my_repeater as $item) { foreach($item->fields as $field) { echo $item->{$field->name}; } }

Lots of info and links about how to handle this - there is more than one approach, so worth reading so you get a better understanding of what is going on:

@homma - here is some reading on this issue: https://github.com/processwire/processwire-requests/issues/56 (sorry, @Gideon So already linked to this)

@Zeka - that's correct - it is only for one branch. To restrict to more than one is a more complex task. Here are a couple of gists that will get you going: https://gist.github.com/adrianbj/e391e2e343c5620d0720 https://gist.github.com/adrianbj/6fd1b770d9ce7a7252b6 Remember there are lots of things that AdminRestrictBranch takes cares of that you will need to consider like adjusting breadcrumbs, admin search results, the Pages > Tree menu, etc if you choose to start with one of these gists. The biggest issue with the "HideUneditablePages" gist module is if an editable page has an uneditable parent - how should that be handled? Anyway, hope one of them gets you going. This is the thread that led to those gist modules:

No - you are experiencing a namespace issue - looks like the function is being defined in the global namespace, but you are calling it from within the ProcessWire namespace.

Not sure what version of PW you are running, but that should work in 3.x. However, try this which should work in all versions. wire('config')->paths->root

The easiest thing with paths is to make use of $config->paths->root. include($config->paths->root.'sendgrid-php/sendgrid-php.php');

A standard php include works fine for me in a hook. Any chance it's a path problem?

Seems like the main problem is that the setKeyAndValidate() method is called on every PW ready(). I just commented that out and load times go back to being normal. I don't know the Tiny API, but I would think it would be possible to either just do this once, the first time the API key is entered, or perhaps if it's needed for each call to Tiny, then it could be called only when one of the hooks is triggered. Perhaps @Roope can take a better look since it's his module.

Any chance you could point us to the module code?

@oma - you can see what @Robin S means here (Tracy Captain Hook panel) - see how $page is the first argument?