Soma

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.

As far as I know a fulltext search with ~= or *= will return results by relevance/score that's built in mysql. But %= is wildcard like search not fulltext. I'm not sure that's by relevance in order of search fields. For far more powerful search that's also fast on very large scale can do fuzzy searches etc, one would have to consider using a tool like apache lucene or elastic search or alike.

Because the page id isn't the key in the PageArray.

Of course you're right. I think it would be possible but maybe little messy. I'm not into this module much (used it once), but maybe on the child editor some feature for setting the active languages via checkboxes would be a better way?

An option when creating would be nice option. It's not always content pages bit also pages as categories etc. Maybe even some field in csv could be used to do it on a per entry basis. I would go for something like this. In the case of such a feature the more option to do such things the better.

It works fine for me all ok. In backend, via API too.

@szabesz It doesn't allow me to rename "php" to "php.old".

It's kinda weird I'm now again trying to use the MAMP options to allow network access. I removed the socket configs I did in mysql and php but mysql log says 160830 15:37:00 mysqld_safe mysqld from pid file /Applications/MAMP/tmp/mysql/mysql.pid ended 160830 15:37:02 mysqld_safe Starting mysqld daemon with databases from /Library/Application Support/appsolute/MAMP PRO/db/mysql 160830 15:37:02 [Warning] Setting lower_case_table_names=2 because file system for /Library/Application Support/appsolute/MAMP PRO/db/mysql/ is case insensitive 160830 15:37:02 [Note] Plugin 'FEDERATED' is disabled. 160830 15:37:02 InnoDB: The InnoDB memory heap is disabled 160830 15:37:02 InnoDB: Mutexes and rw_locks use GCC atomic builtins 160830 15:37:02 InnoDB: Compressed tables use zlib 1.2.3 160830 15:37:02 InnoDB: Initializing buffer pool, size = 128.0M 160830 15:37:02 InnoDB: Completed initialization of buffer pool 160830 15:37:02 InnoDB: highest supported file format is Barracuda. 160830 15:37:02 InnoDB: Waiting for the background threads to start 160830 15:37:03 InnoDB: 5.5.42 started; log sequence number 6123988935 160830 15:37:03 [Note] Server hostname (bind-address): '127.0.0.1'; port: 8889 160830 15:37:03 [Note] - '127.0.0.1' resolves to '127.0.0.1'; 160830 15:37:03 [Note] Server socket created on IP: '127.0.0.1'. 160830 15:37:03 [Note] Event Scheduler: Loaded 0 events 160830 15:37:03 [Note] /Applications/MAMP/Library/bin/mysqld: ready for connections. Version: '5.5.42' socket: '/Applications/MAMP/tmp/mysql/mysql.sock' port: 8889 Source distribution Weird thing is that there's no file : '/Applications/MAMP/tmp/mysql/mysql.sock' in my case. never was.

I'm not sure I want to follow what is written there, renaming php doesn't even work. And I dont' want to modify .bash_profile.

Yes MAMP Pro 3.5 on ElCapitan.

I tried out wireshell and installed it. It seems to work but not when I try to use it on a existing local install. PW Version doesn't matter so far. I'm using MAMP Pro and can't get it to work and always get an error. When using the mysql socket as explained I get: Error: Exception: SQLSTATE[HY000] [2002] No such file or directory (in /Applications/MAMP/htdocs/pw28.ch/wire/core/ProcessWire.php line 293) When using the "allow network access" option in MAMP and using 127.0.0.1 I get: Error: Exception: SQLSTATE[HY000] [2002] Connection refused (in /Applications/MAMP/htdocs/pw28.ch/wire/core/ProcessWire.php line 293) I'm not sure what to try.

Why should it not be available on the front-end? It's just you have to output the stuff in your header. Look at the default.php of templates-admin/. I always use it in my sites. <script type="text/javascript"> var config = <?php echo json_encode($jsConfig); ?>; </script> Then use the config.key in your JS.

Maybe someone enlighten me here. But unfortunately it's not an easy one. Not one I can think of I would be happy with. Not one that doesn't create all the problems I'm trying to solve or stay away. The problem with your idea is that it's not the saving and loading of the urls in the RTE but you're talking about the url field you see when selecting a page. That's the page linke editor that works together with a each PW specific RTE plugin editor on top of that. 1. So, one and easy way would be to alter the $page->url via a hook (as it is now or was), but that's where it will be systemwide changed and many things may and will stop working. Maybe some options there to only alter if-then... but believe me it creates a whole tale of issues that arise in one place or another. Mixing it up with "here you do it but there you don't" etc. 2. The other would to explore the PageEditLink module and probably only JS side to see if it can be somehow hidden, but by not altering the -in and -output. That would be more a cosmetic fix. I'm sure there would e some way or another, although not that easy. While I understand what you're saying that it creates usability issues, I think it can also create problems if you hide something that's relevant information too. Imagine you only see "/about"/ and "/about/" but which is which? We have lot of editors that edit multiple sites and cross linking should be easy. Maybe best way would be to "grey it out" and make them aware that it's "secondary" info due to multisite. The other "problem" here is that it would have to be done for all RTE's etc and upcoming link editor plugins. And as it looks one would have to completely replace some of the complex PW RTE plugins and or the link editor js to make it work, and always try to incorporate changes and new features in the core that will occur in no time for sure (and then there's front-end editing). So it's also a question of how deep this modules should go or stay out of the way and don't create too much dependencies.

Sorry, there's so many iterations and experiments with this module I can't always recall what the current state is. I'm working on and off on this. I forgot the current dev still does alter the urls to strip out the domain segment. So as you seen, PW isn't able to resolve the url anymore. This also created various problems not only with link abstraction, but page path history view links etc etc. Current version I have, works fine here due to NOT rewriting anything in the backend (ready() hooks all commented out + some parsing of the urls on page render). So the only headache free and correct solution is to let them as is. A "/domain1/about/" vs a "/about/" also has some advantage in that it's the physical url and can be recognized and handled in some way if needed while the latter you can't. Domain1 and Domain2 could have both a "/about/" and you don't know which one is which. I guess it's not something we have many options unfortunately. I'm still testing and working on the new version, but have no ETA. So this modules is still in "alpha" and each version may not compatible with one or another previous version (also PW versions) and I still do not recommend using it in a important or critical project and only if you're aware of the consequences it may bring (broken links you can hardly recover).