abdus

I think I've found a pattern. Whenever I switch from my smartphone to PC and vice versa, my session terminates. It acts similar to how $config->sessionFingerprint works. I have a VPN on 24/7 on my PC, so it pretends to be in Amsterdam while I occasionally turn on VPN on my smartphone, so it mostly stays in Turkey. Constant switching between two devices and IP addresses is maybe what sets off this problem.

I couldn't replicate your error, but reading the source, InputfieldSelector gives that error when allowSubselector is set to false. // /wire/modules/Inputfield/InputfieldSelector/InputfieldSelector.module public function sanitizeSelectorString($selectorString, $parseVars = true) { // ... foreach($userSelectors as $s) { if($s->quote == '[' && !$this->allowSubselectors) { $this->error("Subselectors are disabled"); $userSelectors->remove($s); $userSelectors->add(new SelectorLessThan('id', 0)); // forced non match } // ... } // ... return $selector; } Turns out subselectors were actually exclusive to ListerPro module. // /wire/modules/Process/ProcessPageLister/ProcessPageLister.module public function getInputfieldSelector() { // .. $s->allowSubfieldGroups = false; // we only support in ListerPro $s->allowSubselectors = false; // we only support in ListerPro // ... }

How can I trigger the module for all pages (with paired fields) at once? Like mass-updating all pages? Setting field to itself doesn't work foreach($pages->find('template=post') as $p) { $p->of(false); $p->tags = $p->tags; echo $p->save(); } // doesnt work because the module skips the page if none of the paired field is changed public function updatePageFields(HookEvent $event) { // ... foreach($flds as $fld) { $this_fname = $fld->name; // only if the page is not still null and the field has changed if(!$page->id || !$page->isChanged($this_fname)) continue; // ... } } }

There should be at most 1 page with featured=1, but $pages->find() returns PageArray, you'd have to iterate over it but it's just semantics. What I'm interested is how you'd get a hook to run just once and stop further hooks from getting triggered inside that hook.

I'm having this issue for the last week or so. When I sign in, I make sure to check "Remember Me" box, but it doesn't seem to change anything. My account gets logged out after an hour or so, even more frequently on my smartphone. Issue persists in different browsers and devies. I am using a VPN (actually a ShadowSocks proxy) but how I connect shouldn't matter, because session cookies are sent with each HTTP request Does anyone know what's happening and how I can stop this? This is how cookies look when I log out This is after logging in Cookies seem to be set correctly, their expiration is set to 3 months later, but it expires anyway.

Yeah, that could work too

How about something like this? Create a Checkbox field called featured, add it to a template Hook into Page::savedField, return if field name is not 'featured' Check if $page ($page = $event->arguments(0)) has $page->featured=1 Perform a $pages->find("featured=1, id!=$page") Iterate over those pages and set featured=0 Now one potential problem that comes to my mind is that as you're iterating over these pages, the hook will be called over and over. Setting $event->cancelHooks = true before you do the iteration should cancel subsequent hooks, but I haven't tried it.

Does $testID get posted correctly? There has to be a problem with the page id. Can you check the item id again (Admin > Repeaters > some-page-name > repeater-item)?

Getting a page with its id should return that page regardless of its status or access settings. I am able to get a repeater page by its id using $pages->get(1039); https://processwire.com/api/ref/pages/get/ Using $pages->find(), however, takes page access and status into account

Go to Setup > Fields & Setup > Templates, there's two buttons on bottom right that you can use to export/import fields & templates Also, remember to backup your database http://modules.processwire.com/modules/process-database-backups/

There's Multipler Module from @ryan's Profields pack, which will help you a lot and change the way you develop PW. It is a commercial module, but you get to use it on any website once you buy it. https://processwire.com/api/modules/profields/

Yeah, Console is a part of @adrian's Tracy Debugger. It's a great tool to keep under your belt. http://modules.processwire.com/modules/tracy-debugger/

Here's what I did. I set up a Page Reference Field, where client can pick a parent. This means with $page->related_random I can get the parent. Getting its children is simply $page->related_random->children->find(). I then iterate over them and output some data

$maxProducts = 1; $productParent = $page->related_random; $pages->find("parent=$productParent, template=product, sort=random, limit=$maxProducts"); or $page->related_random->children->find("template=product, sort=random, limit=1");

I think I get it now. You want to group children by values of a column Something like this one works: So this code $parent = $pages->get(1017); $groupedByLow = []; foreach($parent->children as $child) { foreach($child->prod_vid_bandwidth as $item) { $groupedByLow[$item->band_lo][] = $child->name; } } ksort($groupedByLow); // sort by band_lo dump($groupedByLow); Groups children like this (I used name field for presentation) array (3) 10 => array (1) 0 => "new-car" (7) 20 => array (2) 0 => "old-car" (7) 1 => "new-car" (7) 60 => array (1) 0 => "old-car" (7) You may need to check for null inside the second foreach.

So, it's similar to this one? Since $child->prod_vid_bandwidth will return a TableRows object, you cant simply do $page->tableField->column, but you can foreach over the TableRows object or extract any column you want

What kind of field is prod_vid_bandwidth? You have a typo. There shouldn't be a period there, it should be an object operator -> like others. Unless I'm mistaken period is used for string concatenation only.

If you define the namespace on top of your script, you wont have to prefix functions with \Processwire\ #!/usr/bin/php <?php namespace ProcessWire; // remember to include namespace include("./index.php"); // bootstrap ProcessWire // ... function createMockUsers() { $u = new User(); $u->of(false); // short for outputFormatting // inside closure you cannot access global $wire variable // unless you set function myFunction() use ($wire) {} // but you can call wire() function instead $u->name = wire()->sanitizer->pageName("newname"); $u->pass = "yo12345"; $u->email = wire()->sanitizer->email("example@processwire.com"); $u->addRole('guest'); $u->save(); } // ... createMockUsers();

You can download the source code for the old skyscrapers demo https://github.com/ryancramerdesign/SkyscrapersProfile Then extract site folder beside wire/ and other site profiles. Then perform setup and check out templates, fields, how PW works. Once you get the hang of it, replace the templates with modern v2 version. https://github.com/ryancramerdesign/skyscrapers2 If you have any questions, ask away

You can use SimpleXML to parse XML string http://php.net/manual/en/simplexml.examples-basic.php Then create new repeater items using API

Check the output of phpinfo() to see whether php extension is enabled. If not, you can install it with sudo apt install php-imagick

Done. I've made a pull request. https://github.com/processwire/processwire/pull/82

I'm trying to add a new option to InputfieldTextarea. Depending on that option, I want to change how the input is rendered. I also want to change this option depending on different templates and repeaters, meaning it can have different values for different fieldgroups. I hooked into three methods: $this->addHookBefore('InputfieldTextarea::render', $this, 'hookInputRender'); $this->addHookAfter('InputfieldTextarea::getConfigInputfields', $this, 'hookInputSettings'); $this->addHookAfter('InputfieldTextarea::getConfigAllowContext', $this, 'hookInputContext'); In hookInputSettings, I build the additional option protected function hookInputSettings(HookEvent $e) { /** @var InputfieldTextarea $field */ $wrapper = $e->return; $field = $e->object; /** @var InputfieldSelect $font */ $font = $this->modules->get('InputfieldSelect'); $font->label = $this->_('Font'); $font->name = 'fontFamily'; $font->addOptions(self::fontOptions); $font->attr('value', $field->fontFamily); $wrapper->add($font); $e->return = $wrapper; } It shows up in field settings with no problem When I pick an option and save, it even shows up in the database. However, I cannot get the properties of that field in that fieldgroup context. Most other inputfields can get their inputfield settings because are inside a class that extends Inputfield, so $this->myOption works. If I hook into FieldtypeTextarea::getConfigInputfields, it works too, because getConfigInputfields method is called with $this as its argument, inside hooks it's possible to access fieldgroup specific settings. But for Inputfield, it's not given any arguments, so hooking Inputfield::getConfigInputfields, you won't be able to get any information about the context. // /wire/core/Field.php public function ___getConfigInputfields() { // ... if(!$fieldgroupContext || count($allowContext)) { // ... try { $fieldtypeInputfields = $this->type->getConfigInputfields($this); // ... } // ... } $inputfields = $this->wire(new InputfieldWrapper()); // ... if($inputfield) { if($fieldgroupContext) { $allowContext = array('visibility', 'collapsed', 'columnWidth', 'required', 'requiredIf', 'showIf'); $allowContext = array_merge($allowContext, $inputfield->getConfigAllowContext($this)); } // ... $inputfieldInputfields = $inputfield->getConfigInputfields(); // ... } // ... } So, as a solution I gave it $this as a parameter // $inputfieldInputfields = $inputfield->getConfigInputfields(); $inputfieldInputfields = $inputfield->getConfigInputfields($this); Now everything works without any hacks. It works in field settings, templates, repeaters just fine. protected function hookInputSettings(HookEvent $e) { // ... $field = $e->arguments(0); // ... $font->attr('value', $field->fontFamily); // WORKS! // ... } I wanted to write this post because it drove me mad last night. I guess the next step is to make a pull request.

I can confirm that I have the same issue. Not selector doesn't seem to have an effect.

I've just tried to assign custom integer values as @oma did, and I'm having the same issue. Once I submit, PW tries to delete former options as well. This is probably the intended behavior. and once I confirm to delete those options, I get unique incremential ids for the new options Checking the database entries, it seems value field isn't filled at all, instead option id is returned I'd say there's definitely a bug here.