Robin S

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.

Can you give a more detailed report please? What are the image URLs you are trying to add when you see the error notice? Is the issue reproducible? i.e. if you try again with the same URLs do you see the same notice? If you download the images to your computer and then upload as per a normal addition to an images field, do they work then? Anything special about your images field - e.g. inside a Repeater or PageTable? The error seems to be related to the field name. Could you please post a screenshot of your browser dev tools showing the source code of the textarea input that this module adds to the images field (like the one below)? That will help me get to the bottom of this. Thanks.

Yeah, that is difficult. Instead of including a copy of InputfieldIcon, another approach could be to auto-install a custom inputfield module (e.g. InputfieldIconFaPro). Then hook into the form rendering of ProcessTemplate and ProcessField and remove the existing inputfield, adding InputfieldIconFaPro in it's place with the same name (so it still reads/writes the "icon" property). Here are the classes (got them with some regex find/replace in file web-fonts-with-css/scss/_icons.scss):

Ha, sorry. Not expecting delivery of the all-singing, all-dancing image reference module. What I meant is that due to needing to be kept in sync with the feature set of the core image inputfield/fieldtype, a full solution for an image reference fieldtype probably needs to come from Ryan, either as a core feature or a pro module. But I don't think we can expect that any time soon.

Looking good! Thanks for working on this. PW really needs an "image reference" fieldtype (wishlist topic). Several times I've thought about tackling it, but seems like a lot of work because users will be expecting a feature set matching the core images inputfield: sortable, scalable thumbs, different thumbnail views, etc. Not to mention new challenges like setting tags or description on the reference that is different from the source tags/description, how to handle deletion of the source image, etc. Quite tricky.

Ah, I should have known there would be something in PIA for this - it's the real Swiss Army Knife for images. I really need to have a proper explore of that module. (I think it's the state of the docs that has been putting me off - maybe you could consolidate/tidy everything into the GitHub readme?) I have a very primitive system. For modules I'm interested in I have a spreadsheet with name, category, link, brief description of what it does (in my own words). But I often forget to update it with new modules and just try to rely on memory. For forum snippets (and links to the original post) I just have a folder with a bunch of text files in it. The text files are named according to what the snippet is about. Then when I'm looking for something I use the quick filter feature in my file manager (XYplorer).

Actually, you can shorten the CSS override to this: .cke_panel_list * { font-family:sans-serif, Arial, Verdana, "Trebuchet MS"; font-weight:normal; font-style:normal; font-size:14px; }

And if it's mainly within CKEditor fields that you want to reuse images from a central media library then there is this module from @BitPoet: Media Library

In /site/modules/InputfieldCKEditor/contents.css: .cke_panel_list h1, .cke_panel_list h2, .cke_panel_list h3, .cke_panel_list h4, .cke_panel_list h5, .cke_panel_list h6, .cke_panel_list pre, .cke_panel_list address { font-family:sans-serif, Arial, Verdana, "Trebuchet MS"; font-weight:normal; font-style:normal; font-size:14px; } Do likewise for any custom styles you have added to the Styles dropdown.

Here's an alpha proof-of-concept module if anyone is interested in taking it further: https://github.com/Toutouwai/FieldtypeFileUnrenamed/