valan

When switching template schema to HTTPS I loose incoming params that were included with HTTP address. How to avoid this?

Yes, there are a lot of separate discussions, but I haven't seen any discussion "next top big 3 things that we, as PW community want to have first". Otherwise please share a link. Thanks. P.S. My like to comment "don't try..."

@teppo: thanks for sharing thoughts! fully agree that core should be as small and lean as possible and module system is the answer for all kind of additions. My point is that MVC, payment system and bootstrap3 deserve to be among core modules (first two can be plugged in when required, last one better to have as default choice instead of Jquery UI).

One more point, 5: Sooner or later every web-developer meets challenge of "complex" site where MVC framework becomes a necessity. It is great that PW does not impose requirements on "what&how" and web-developers are free to choose own MVC implementation scenarios. However, it is not easy to choose "the right one" way, especially for those who meet this challenge first time. When I've met this challenge I've missed "optional PW MVC" (in core/in PW API) and had to spend time, inventing own one. It is good for own skills but not for project timing. ) And as any custom/non-standard thing it has its drawbacks. E.g. why not to add standard but "optional" PW MVC (in core) that will be quicker to implement and easier to support for all those who are advanced enough to switch to MVC.

Re 1: Wow. Super. Checked it - work is actually in the very beginning but it has right direction. Joined the topic to follow/participate. Re 2: That would be fantastic! Re 3: Yes, there is mix. I mean that bootstrap3 should be an option in default site profile and admin should be designed in it (= bootstrap3.css + bootstrap3.js as basis with minimal custom.css and broader-set-of-inputfields.js). After that Inputfields can be used "as is", without need to adjust css or add/replace js in front-end. As for mode of entry, I mean this -> http://vitalets.github.io/x-editable/ Re 4: Tutorials are important in the beginning of journey, especially for newcomers. But a bit later most help queries stop in http://stackoverflow.com/ )) And there is good reason for that: quickly get best answer.

I've married PW about 2 years ago and I feel happy today. However, this fact also gives me some rights to share thoughts how to direct PW development with the objective to speedup popularity and better fuel its development. List below - something that is on top of my mind. Sorry if I'd repeat already discussed topics. The purpose is to summarize really top "big" things in one place and give core team source for thoughts. 1. Any more or less popular/really important site needs a development "copy" and usually test "copy", were developers/testers can do whatever they want, passing changes through dev->test->production approval chain. These features should attract more web-developer teams and those who do something bigger than personal blog-site. ) Ideally this should be integrated with git/bit-buckets to make version management easy. 2. Any more or less "commercial" site needs well-developed "payment plugin". Existing PW plugin(s) are far from desired state. I'd suggest to make it and place it in core. This should attract more "commercial" web-developers into PW and those who consider PW as next CMS but don't have good PHP background. BTW, I'd suggest to consider https://github.com/omnipay/omnipay as a basis for such "to-be" PW plugin. 3. Most popular front-end framework is bootstrap. Why not to "bootstrap3" PW admin? It will close the gap btw frontend UI and admin UI (forms, inputs, etc) for majority of web-developers. E.g. no need to design own forms/inputs and to some extent server logic, etc. There is great Ryan's Formbuilder module, but I talk here about design & custom forms for non-generic use cases. Also, number and design of input fields should be reviewed to close at list 80% of web-developer needs. I'd also welcome "save-as-type" mode of entry vs current "type-find save button-waitrefresh". 4. PW community has grown and forum has become a hard place to find answers quickly, especially for new PW-engaged people. Actually what any web-developer needs is manual (like PHP manual) and stackoverflow q&a system. May be it is time to open PW stackoverflow, while maintaining manual? Additions/corrections/critics - welcome!

One of the greatest tools for big sites. I only miss action "Change Field". @Wanze - would be super to see this action in future updates. Thanks!

@thomas, @martin - thanks! Looks like the only option is to disable expire Markup Chaches when pages are saved and install module below. And the way to tell it when not to expire instead of when to expire is as below. class DeleteMarkupCache extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'Delete cache module', 'singular' => true, 'autoload' => true ); } public function init() { $this->pages->addHookAfter('save', $this, 'deleteCache'); } public function deleteCache($event) { $page = $event->arguments[0]; $notExpire = ['template1', 'template2']; if(in_array($page->template, $notExpire)) return; $cache = $modules->get("MarkupCache"); $cache->expire(); } }

In module settings there is a "yes/no" question: "Expire Markup Chaches when pages are saved?" As far as I understand, if "yes" is enabled then MarkupCache get triggered on page save, and it deletes all cache. I want to keep "yes" but want to stop trigger MarkupCache (=cache deletes) when some specific pages are saved.

May be my request is not clear enough or I don't understand the answer... I don't need to trigger delete of the cache - by default it triggers after any page save. This is a default setting in Markup Cache module. Instead, I need to stop trigger for certain pages. I need to do it at API level in my code, e.g. not in PW core.

Is it possible to disable markup cache expiration at API level when I save certain pages? Hook? Could you please share an example? Module settings allow only yes/no setup for the whole system but I'd like not to inform module on several page save events while keeping "expire" for all other pages. Thanks! P.S. I've checked ProCache docs but it looks too big and UI-oriented for this task.

Cool!

Thank you guys! With correction (see http://us1.php.net/manual/en/function.array-diff.php) this seem to be the best option: $a1 = $array_1->explode('id'); $a2 = $array_2->explode('id'); if((count(array_diff($a1, $a2)) + count(array_diff($a2, $a1)))===0) echo 'identical'; Would be great to see in PW core something like $a1->isIdentical($a2) as such kind of comparison is not rare (at least in my projects) !

...and ideally fastest way. Where "equal" means that both arrays have the same set of elements, while order may be different. Straightforward way is to use double foreach, but I'm wondering if there is more elegant way with selectors and PW API.

Pete, Dave - thanks for suggestions! Looks like there is no other way than to create additional field. dragan - I think %= won't work due to issues with quotes in json string.

There is template "mytemplate". There is field "myjson" in this template that stores json string. What is the most performance-effective way to check if a given json string already exists in some page using PW selectors? // this code doesn't work due to selector quote issues $query = 'template=mytemplate, myjson=' . $json; if($pages->count($query)!==0) ... // this code doesn't work as sanitized json string is not equal to original json string $query = 'template=mytemplate, myjson=' . $sanitizer->selectorValue($json); if($pages->count($query)!==0) ...

Or it returns existing image, if image with such dimensions already exists (e.g. has been created formerly)? Or in other words - do I need to cycle through $image->getVariations() in order to minimize load onto the server? Or there is another/PW-way to get specific image variation, without image generation if it already exists? Thanks in advance for tip!

I've upgraded to PW 2.3.11 and problem disappeared. Thanks!

Thanks, Ryan! Unfortunately I'm not familiar with traditional web service communications but looks like I have to... Running several instances in one script could be a great addition for entry-level coders who actually like PW and don't know (or don't want to know) how to dig sql dbs. Such functionality significantly reduces a need to know sql as now you can use PW in "external storage" scenarios. E.g. storing any shared catalogs in dedicated PW instances and have the same interface, api, maintainability through PW admin, etc. By the way, I guess that new api variable should be called $wires .

I'm developing relatively big site with a number of weakly connected web-services. By "weakly connected" I mean that they share same users and some common catalog but the rest (and bigger part) is not shared (service-specific catalogs, languages, etc). As site becomes too big and complicated I think to move these weakly connected web-services to their own sites, e.g. one PW core but several sites with their own dbs. Users as well as shared catalog remain at "main" site, being maintainable via PW admin. Before this move I'd like to consult with you guys. Specifically - would this code work at "web-service" sites? $temp = $wire; // temporary save "current site $wire" include("../../../site-main/index.php"); // bootstrap PW main domain $wire. Main domain and Service domain sites are in one directory, ../../../ path prefix used to navigate from current templates directory to common parent folder of all sites. $mainWire = $wire; // set variable to be used for access/manipulations at main site $wire = $temp; // set $wire back to "current site $wire" $user1 = $mainWire->users->get('email=email@example.com')->first(); // returns User instance from main site / main domain db $user2 = $wire->users->get('email=email@example.com')->first(); // returns User instance from current site / current domain db I am aware of http://modules.processwire.com/modules/service-pages/ but due to security&performance reasons I think that if "hardcode" above works then it should be a better choice. P.S. wire/index.config.php function ProcessWireHostSiteConfig() { return array( 'maindomain.com' => 'site-main', 'www.maindomain.com' => 'site-main', 'service1.com' => 'site-service1', 'www.service1.com' => 'site-service1', 'service2.com' => 'site-service2', 'www.service2.com' => 'site-service2' // etc other services ); }

ups... I didn't realize that modules now have separate Core tab finally perfectly works! Thanks, Soma.

OK, I've uninstalled it but result is the same - no tabs...

I've recently migrated from PW 2.3.1 to PW 2.3.11. Everything seem to work fine except this module. I've re-installed it but w/o success. What could be a reason?

Thanks! Also would be great if you can add few lines in usage describing how to setup simple UI - currently there is only ugly browser button. I guess UI customization should be somewhere in plugin docs but some simple starting point would be useful here too. Thanks!

Hi boundaryfunctions! I'm following installation/usage steps but get error "Upload field name name not specified" which is returned by handleUpload(), line 62. Please could you check what could be a reason? Thanks!