Robin S

Is there a WireArray equivalent of PHP's array_search() function? In other words, if I have a value and I want to know the key of that value (if any) for a given WireArray, how can I do that? I checked the WireArray docs but didn't find any equivalent, which surprised me because array_search() is a pretty commonly used function. Would the only way be to convert the WireArray to a plain PHP array with getArray()?

As before, you can't easily modify ProcessPageList for this purpose. But you can use Lister (Pages > Find). So in your case you would filter according to some parent or some template, plus filter by "title starts with" some character. I have a module under development that will allow for a list/tree that dynamically changes the selector used by Lister. Not sure when it will be ready but that might end up being helpful for your scenario.

Yeah, that module wouldn't really be practical if you need more than one or two virtual parents. The Virtual Parents module was an experiment to answer the question "To what extent is it possible to trick ProcessPageList into showing a page structure that isn't real?" And now that I've tried it I can answer with "To only a very limited extent". ProcessPageList just isn't designed to support anything other than the real page tree and forcing it do otherwise is pretty painful. There have been several requests for a way to browse an alternative page structure. It will require a module that builds its own tree from scratch and doesn't rely on ProcessPageList. It's on my to-do list but it will be challenging and I'm not sure when I'll get to it. And bear in mind too that any module like this will come with other limitations - for instance, it wouldn't be possible to sort or move pages like ProcessPageList can because the page structure shown might have no resemblance to the real structure.

@adrian, I created a pull request for adding support for Repeater Matrix to the "Copy Repeater Items to Other Page" action. It only required a small modification to the field select options so I thought it best to keep this within the existing action rather than create a new action just for copying Repeater Matrix fields. I thought about allowing all fieldtypes that extend FieldtypeRepeater but decided it would be better to add fieldtypes on a case-by-case basis just in case someone has a custom fieldtype that extends FieldtypeRepeater in some weird and wonderful way that wouldn't be compatible with the action. I also added a couple of other enhancements to the action - failure conditions for if the selected repeater field doesn't exist on the source or destination pages (previously the action reported a success in those cases). And copying repeater items now also copies any files or images included in the repeater items. One last thing I added, to the module itself this time, is a link to the module config settings in the notice that advises that new actions are available. I think it would also be handy to have a link the config settings in the process page - I often want to jump there to adjust allowed roles and the "in menu" option. I didn't include this in the pull request though - just something for you to consider.

@Zeka, maybe you can use the filename, prependFilename or appendFilename properties of the TemplateFile to limit where your hook applies. E.g. $wire->addHookAfter('TemplateFile::render', function(HookEvent $event) { $template_file = $event->object; $proceed = false; foreach($template_file->appendFilename as $filename) { if(substr($filename, -9) === '_main.php') $proceed = true; } if(!$proceed) return; // Your code... }); I'm curious - what's your reason for hooking after TemplateFile::render? If you are targeting non-admin template files inside your /site/ why wouldn't you include whatever logic you need inside the template files rather than via a hook?

This module requires Repeater Matrix which is part of the Profields bundle. The Matrix module you have shown in your screenshot is something completely different.

@OllieMackJames, your setup makes sense to me. But you cannot clone the Home page because there can only be a single page at the top of the page hierarchy. Instead you need to move the Home page contents to another page... Add a new template with the same fields as your home template (use the "Duplicate fields used by another template" option when adding it). Create a new page using this template. Now check out @adrian's Admin Actions module which has two built-in actions that you'll find useful to move the content from the existing Home page to this new page: 1. Copy Repeater Items to Other Page 2. Copy Field Content to Other Page Another tip: If when setting up a site you know that you will later want to turn the Home page into an internal page you can make it easier by using an internal page to hold your Home page content. Let's say this internal page has the ID 1234. Don't publish this page (so it won't be accessible on the front-end). At the top of home.php (your home template file) you put... $page = $pages(1234); ...and now wherever you do $page->title etc in home.php you will get the content from page 1234. Later when you are ready to switch the Home page you can populate your home page with content (or repeat the steps above for a different unpublished internal page), remove/change the $page assignment in home.php, and publish page 1234.

Also note that in PW3 wireRenderFile() and wireIncludeFile() are $files->render() and $files->include() respectively (those earlier functions now just call the $files methods internally).

PhpStorm doesn't know what API variables PW makes available to template files. So you need to add variable types hints in a DocBlock at the top of your template files. I use... /** * @var Config $config * @var Fieldgroups $fieldgroups * @var Fields $fields * @var Languages $languages * @var Modules $modules * @var Page $page * @var Pages $pages * @var Paths $urls * @var Permissions $permissions * @var ProcessWire $wire * @var Roles $roles * @var Sanitizer $sanitizer * @var Session $session * @var Templates $templates * @var User $user * @var Users $users * @var WireCache $cache * @var WireDatabasePDO $database * @var WireDateTime $datetime * @var WireFileTools $files * @var WireInput $input * @var WireLog $log * @var WireMail $mail * @var \ProCache $procache * @var \FormBuilder $forms **/ Your field names are not a part of the PW API (field names don't exist in the file system but only in the database). But I believe you can get code completion for field names using the Template Stubs module.

No, a form doesn't work that way. The way you have it set up now you have a single form with multiple submit buttons. It doesn't matter which submit button you click, the submitted form data will be the same. The thing is that the name of each post variable is determined by the name of the input element it corresponds to. Where you have multiple inputs with the same name (which you will have unless you rename them using something like what I suggested before) only the last input of each name will actually make it into post. Although you could change to having multiple forms (one for each grandchild page) I don't think the idea of multiple submit buttons is a good one. Where users see multiple fields from multiple pages in the same module interface the expectation will be that they can edit all of these fields at once. But in fact all changes they make besides those inside the form they click the submit button for will be lost. Users might not notice that which could cause problems, or they might notice it and report it to you as a bug. You don't really want either of those. A single form with a single submit button would be better, then you loop through the submitted form data and use the added page ID prefix to connect it to the relevant page. But remember you need to sanitize all the submitted data. It looks like you're sort of recreating ProcessPageEdit with your module here - have a look at ProcessPageEdit::processInput to get an idea of the kinds of things to look out for. If the action of your form points to your Process module page (which it will do by default unless you changed it) then all the post data will be accessible in the init() method of your module, as you are already trying. But as I said above, the array of data is in $this->input->post. You mentioned you have Tracy installed - so do... bd($this->input->post); ...in your init() method and you will see the post data you have available.

$this->input->post->submit is a single post variable with the name "submit". To get all your post variables you want to use $this->input->post. But I think you will find a problem in that if two or more of your grandchildren pages share the same the same template then the inputfields on those pages will share the same names. Meaning that the post variables will be overwriting each other when the form is submitted. So you will need to find a way to rename the inputfields in your form so each inputfield has a unique name. Something like this might work, which prepends the page ID to the inputfield name: // ... foreach($inputfields as $field) { if(in_array($field->name, $ignorefields)) continue; $field->name = $grandchild->id . '_' . $field->name; // make name unique by prepending the page ID $fieldswrapper->add($field); } // ...

The bare bones are: $form = $this->modules->InputfieldForm; $parent = $this->pages(1234); // Get the parent page foreach($parent->children as $child) { if(!$child->hasChildren) continue; $fs_level_1 = $this->modules->InputfieldFieldset; $fs_level_1->label = $child->title; $fs_level_1->collapsed = Inputfield::collapsedYes; foreach($child->children as $grandchild) { $inputfields = $grandchild->getInputfields(); $fs_level_2 = $this->modules->InputfieldFieldset; $fs_level_2->label = $grandchild->title; $fs_level_2->collapsed = Inputfield::collapsedYes; $fs_level_2->add($inputfields); $fs_level_1->add($fs_level_2); } $form->add($fs_level_1); } // Add submit button or anything else here // ... return $form->render();

Markup Regions are a godsend if you want to code HTML directly rather than adding it as strings to PHP variables. Alternatively you can use output buffering (which is what I preferred before Markup Regions were introduced). <?php ob_start(); // $main_content ?> <div>Your markup</div> <?php $main_content = ob_get_clean(); ?> For a project like yours I would be inclined to try building it within the PW admin as a first approach - you can do a lot with the admin (it's just an application built using the PW API) and it's pretty easy to tweak it with hooks and custom CSS. I think it would be much quicker that way. @bernhard has written a helpful blog post for getting started with Process modules, and check out his Showcase topic for the kinds of things that are possible:

Not totally sure what you mean - you just want to save having to click "Add Filter" to add an email address row? You can use a hook in /site/ready.php: $wire->addHookBefore('ProcessPageLister::execute', function(HookEvent $event) { if($this->config->ajax) return; $process = $event->object; // Just for the Users lister... if($this->page->name === 'users') { // Add to existing defaultSelector (or alternatively you could overwrite defaultSelector) $process->defaultSelector .= ', email%='; } });

Not sure what kind of plugin you used, but you don't need a plugin to do this task in any case. I'd start over and migrate using a procedure like this: Export database from local server using phpMyAdmin or similar. Make ZIP file of all local website files. Create new database and database user at 1&1. Try to use the same database name and user name as your local site if possible, but no big deal if not possible - you'll just need to edit the details in /site/config.php to match. Import database from step 1 to the new database you created at 1&1. Upload ZIP file from step 2 to public_html root. Extract ZIP file (assuming that 1&1 has a file manager that supports unzipping - otherwise you'll have to upload all the website files uncompressed which will take a lot longer). Done.

v0.1.2 released - adds compatibility with PW < 3.0.66

@hezmann, if you can give me access to your dev site (send me a message) I would be happy to take a look. Otherwise I'm out of ideas sorry.

It's working here in Firefox, and it's unlikely that there will be a difference between browsers in how that JS works. I think it must be a caching issue. Please visit Modules > Site and click "Refresh", and then scroll down and click "Clear compiled files".

Yes, it can. See the blog post about the user-admin permissions.

@MarcoPLY, this topic is about setting the selectable options for a field via the API. As far as I can see your question isn't related to that so would be better asked in a new topic. If you have a "multiple values" options field you cannot simply echo the field value. You have to loop over the field value in a foreach() or perhaps use implode() to create a string from the value. Here is one way you could try: <?php foreach($page->children() as $product): ?> <?php $image_sta = $product->img_statica->first; $classes = ''; foreach($product->category_4 as $option) $classes .= " $option->title"; ?> <div class="mix<?= $classes ?>"> <img src="<?= $image_sta->url; ?>"> <h3><a href="<?= $product->url; ?>"><?= $product->title; ?></a></h3> </div> <?php endforeach; ?> Also check out the documentation for the Select Options fieldtype.

@hezmann, please uninstall the module and then install the attached version. Please let me know if it resolves the issue or not. AddImageUrls.zip

@Nick Belane, the issue with multi-language fields is hopefully fixed in v0.1.2. Please update and let me know if you are still seeing an issue. Thanks @adrian for debugging help.

Nothing obviously wrong/messy with those panels for me with v4.9.9 on Windows 8.1. Maybe some other factor comes into it. Thanks for the update though!

@Nick Belane, you don't need to name file fields in any special way. There should still be a dropdown even when there are no files that can be linked to. See screenshot: So if you are not getting a dropdown then my guess is that there could be a Javascript error. Do you see any JS errors in the console panel of your browser dev tools? I don't know anything about multi-language sites sorry (no demand for them in my country). Maybe someone else can confirm if the module works or not with multi-language?

I think they're counting each variation of an icon (solid, light, etc) as a separate icon, but these variations use the same class name. Typical marketing stuff to puff up the numbers. Maybe the brands font should be loaded by default rather than being optional, because if it isn't loaded it leaves unrendered icons in the list which might confuse users about what the problem is.