Soma

I can confirm this even without testing. I noticed that ProcessWIre is getting slower and slower each iteration. Even 2.73 was slower than all the previous. But seeing what all gets added to PW of course the overhead grows. Also PW is very heavy on the server side and especially DB side and it can get somewhat slow really fast and produces tons of queries. We have very big and complex sites that suffer from some sort of performance issues due to so many table joins and not well indexed tables (said our hoster). We also are currently letting them investigate and may have some details soon. I just did a quick install of 2.73 and 3 master, and can confirm the ~30% slower.

Where comes the this from? Is this a class? Complete code? Usually it's because of the scope. Inside function you don't have this. Try this somewhere before ajax(): var that = this; then in the callback functions: that._Pagelist.set()

I don't know how your menu dropdown logic works but you have 'has_children_class' => 'dropdown', That adds to the <li classs="..."> and you have 'inner_tpl' => '<ul class="dropdown">||</ul>',

I just updated the Captain Hook cheatseheet to latest version 3.x now there's a master and dev version. Thanks to @owzim for providing a cli script to parse the repos automaticly and generate a array to use. It helps a lot to update. https://somatonic.github.io/Captain-Hook/index.html

There's various ways to do it. Simplest maybe to ignore certain templates use the selector option. ie "template!=blog".

The class is on the li if you don't change the options to not do it. You currently add the active class ot the a element yourself in the options. The list tpl misses the %s which will get replaced with the state classes. It should be default 'list_tpl' => '<li%s>||</li>', And default is this 'item_current_tpl' => '<a href="{url}">{title}</a>',

@diogo No never experienced that. I can bootstrap normally. What version are you using?

Thanks for reporting. I think it's kind of a mess The newest dev2 version doesn't have hooks (ready()) as to let the internal url for a page untouched. Therefor the replacing href urls on the render output and adding a request logic to redirect to the multisite url was necessary. Unfortunately this leads to problems to the setup you have. It currently assuming the multi domains are setup all in the root. I'm not seeing through all this as it gets kinda complex and not sure how the login can be changed to achieve what setup you have.

Moved to "Dev Talk" as it's not PW related.

I think that should still work. A domain as root (just no config for it) and other domains on the parent root. But then links won't get parsed correctly, as it doesn't "know" the main domain.

No, the new versions does only support to have all domains in the root.

That's why the settings are in config.php https://github.com/somatonic/Multisite/tree/dev2#add-multisitedomains You'd have a config already for both so it's just a matter of having different domain and the root in PW stays the same.

Wanted to mention that there's a new dev version https://github.com/somatonic/Multisite/tree/dev2 that we are testing and using right now. It was tested and works with multilanguage and PW3 various features.

That plugin for c5 seems to do exactly same approach and share same issues. It mentioned as for simple use cases. Only difference is that their plugin costs 80 bugs.

I have no idea to be honest. I would also remove the autoload config since it a process module that shouldn't be autoload as it's loaded when the admin page is loaded. Also would add the other module infos as needed like summary. Otherwise I never had any problem with this. I would recommend giving all the infos about your setup and versions. And try the ProcessHello I linked to, if that installs ok. Otherwise you may have some other related problem with your install.

Not sure but use this: $pg->process = $this; Since some time you can also do this in the module info as an array: 'page' => array( // optionally install/uninstall a page for this process automatically 'name' => 'mymodulename', // name of page to create 'parent' => '', // parent name (under admin) or omit or blank to assume admin root 'title' => 'My Module', // title of page, or omit to use the title already specified above ) https://github.com/ryancramerdesign/ProcessHello/blob/master/ProcessHello.info.php

It should be mentioned that the getById() is used internal and not access or status aware. So it's like get(id) and will load the page(s) even if they're unpublished or the user has no view rights, all a $pages->find(...) does.

You can't store Objects in session.

Because it does a db search vs a in memory match thats why it doesn't validate. It's like this ever since. There was even several threads and git issues about this.

You have to use the role Id instead of the name.

I recommend not doing such a hook in the admin as it creates a lot . f problems. If then only on frontend.

I think it should happen automaticly after the install from a profile. My guess is that the profile export-import possibility (haven't used it in ages) was made/built before processwire used module caches. My module isn't meant for system cache like the module cache, but rather the various template caches. Since there's already a handy refresh modules button/function.

If you're logged in you have no template cache, unless you enable it for logged in users. That's enough most of the times. There's also whitelist for POST and GET for template cache. So simply adding "nocache" to the GET field when enabling template cache would let you see non-cached version by simply adding /?nocache to a url. The only way to disable template cache via a config, the only way would be to make a hook before Page:render() and set the "allowCache" render option to false. Somewhere in an autoload module public function init() { $this->addHookBefore('Page::render', $this, 'hookRenderPage'); } Then the method to set the arguments for "allowCache" to false if config disableTemplateCache is true public function hookRenderPage($event){ if($this->config->disableTemplateCache){ $args = $event->arguments(1); $args['allowCache'] = false; $event->setArgument(1, $args); } } Now one can add to the config $config->disableTemplateCache = true;

I'm not sure why this is a hack? My multisite module modifies the $_GET['it'] to archive the routing, which was originally even a snippet from Ryan. Even ProcessWire core (Language modules) does this.

Thanks. Yes the facebook grabs the image from wherever it finds it first.