gebeer

Thanks a lot but no need. What are you doing with the form data once it is submitted? Instead of using my hook to alter the value in the form it would be much easier to hook into the processing of the form and get the email there from the ID and save it (just like @wbmnfktr suggested).

The option value is not visible to the user of the form. What are you using this form for and why do you need the option values to be email instead of ID? Please describe what you want to do with that form data. Maybe I should have asked that question before posting my solution above ?

Depending on what kind of page reference field you are using, you could achieve that with a hook, for example in site/ready.php. In this example I am using a page reference field named 'page_reference' and as the Input Field Type I am using a Select field. Now I hook into the Inputfield::render method with a before hook: // use before hook to alter options passed to the Inputfield $wire->addHookBefore('InputfieldSelect::render', function ($event) { // return; if($event->object->name != 'page_reference') return; // build our new options array $options = array(); // $event->object->options is an array of options originally passed to the InputField foreach($event->object->options as $id => $title) { $options[$this->pages->get($id)->name] = $title; // exchange name for email } // set our new options to the InputField $event->object->options = $options; }); This sets the value of the <option> tag to the page name. you can use $this->pages->get($id)->email to set the emails as value. Don't know where you render that form. If it is a custom form somewhere, this should do. But be careful if you plan to use this in the PW page editing form. You will need to take some extra steps when saving the page. Because PW needs the ID of the page to be saved. In that case you can have a look at InputfieldPage::processInput and hook into that to revert your email values back to IDs.

Not sure. Since the Output method is working fine, I haven't tried other methods :-)

Thank you. I had googled but din't find that link which is quite enlightening. Seems like Mpdf's Output method sets different headers than $files->send() does. I will check what headers are set exactly and can then amend the $files->send() method using the headers option to pass the headers that Safari likes. Cheers!

Facing a strange issue with $files->send() method creating this error only on Iphone Safari: "Cannot parse response". On all other clients it is working fine. I am creating a pdf with @bernhard's RockPdf module (which basically is a wrapper around Mpdf library) and sending it for download to browser $pdf = $modules->get('RockPdf'); // ... $mpdf = $pdf->mpdf; // ... $mpdf->WriteHTML($header . $job->render(array('noLinks' => true))); // send $options['noLinks'] for pdf output to not render as links $filename = $input->urlSegment1 . '.pdf'; $saved = $pdf->save($input->urlSegment1 . '.pdf'); if (isset($saved) && $saved->path && file_exists($saved->path)) { try { $files->send($saved->path, array('exit' => true)); unlink($saved->path); } catch (\Throwable $th) { $log->save('pdfdownloads', $th->getMessage()); } } When using Mpdf's native Output method, the rror does not occur $pdf = $modules->get('RockPdf'); // ... $mpdf = $pdf->mpdf; // ... $mpdf->WriteHTML($header . $job->render(array('noLinks' => true))); $filename = $input->urlSegment1 . '.pdf'; try { $output = $mpdf->Output($filename, \Mpdf\Output\Destination::DOWNLOAD); // send to browser } catch (\Throwable $th) { $log->save('pdfdownloads', $th->getMessage()); } exit(); Since PDF generation and Mpdf's native Output method are working fine it seems that $files->send() is the culprit here. Honestly, I have no idea what could cause such a behavior only on Iphone's Safari. Any insights by someone who has more background knowledge on this would be much appreciated.

Never used it together with the Combo Pro module. Actually, I didn't even know that a Combo Pro Module exists ? Is it part of the ProFields package? Then I could have a look at it. And that is exactly what I meant when I said that it is hard to cater for all possible setups. At least I managed to make my module work well with the Repeater Matrix Pro Field ? Edit: Just saw your thread Since my module behind the scene is working with PageImage objects and is storing data in multiple columns, I don't think it is possible to make it work with the Combo Field ATM. Would have to look deeper into how Combo Field is storing data, but, unfortunately, do not have the resources. Not until mid to end of October.

Thank you for asking. Not really. Apart from having limited resources for supporting the module. Most of the bugs mentioned in this thread should be fixed. Have it running in production on 2 sites with no problems so far. But there are so many different setups that people run their sites on so I was still not confident enough to release it as an official module.

I experienced the same. Just loading the InputfieldDatetime module does not apply the required classes to initialize the datepicker. I also had to manually load the module assets from InputfieldDatetime module. They were not loaded automatically by loading the module. This is my working code: $f = $this->modules->get('InputfieldDatetime'); // load module $this->config->scripts->add($this->config->urls->modules . 'Inputfield/InputfieldDatetime/InputfieldDatetime.js'); // load module assets $this->config->styles->add($this->config->urls->modules . 'Inputfield/InputfieldDatetime/InputfieldDatetime.css'); // load module assets $f->attr('name', 'deliverydate-' . $id); $f->addClass('FieldtypeDatetime InputfieldDatetimeDatepicker InputfieldDatetimeDatepicker1'); // manually assign classes $f->label = ('Lieferdatum'); $f->inputType = 'text'; $f->datepicker = \ProcessWire\InputfieldDatetime::datepickerFocus; // this does not work. datepicker widget does not appear on focus $f->dateInputFormat = 'd.m.Y'; Another little thing that I could not get to work is triggering the datepicker on focus of the inputfield. My field looks like this and the user has to click the calendar icon to make the datepicker appear.

On another sidenote, in this part of your code if ($input->get){ ... }else { ... } $input->get will always return true, even if you do not have any GET parameters in your URL because $input->get returns an WireInputData object. You should use if(count($input->get)) // returns 0 if there are no URL params instead.

Just stumbled over the same problem: ProcessPageView::pageNotFound hook only working in init.php, not in ready.php Should be mentioned in the documentation. I just opened an issue.

In your code you are storing an array $portfolio to the cache. To store HTML you would use the same logic as for storing an array but store an HTML string instead. How you create the HTML string is totally up to you. It could be the return value of a $page->render() call or anything else. Simplified example $response = $cache->get('my-html-cache'); if (!$response) { $html = $page->render(); // render a page // OR $html = $files->render('path-to-template.php'); // render page data with a custom template file // OR $html = '<h1>Cached Headline</h1>' // simple HTML string $cache->save('my-html-cache', $html, "template=portfolio"); }

A GET parameter is the way to go here, as @rash suggests. You could also use the template name in the get parameter <p><a href="<?= $item->url ?>?template=news-detail">read more</a></p> and then in your news.php template do something like if($input->get->template && $template = $input->get->text('template')) { // check for GET parameter 'template' and sanitize $files->include("{$template}.php") // use $files API to include the template. All API variables (like $page) will be passed } else { // your regular news.php template logic logic goes here }

Absolutely makes sense.

Wouldn't it be better to avoid commas in URLs? According to the URI RFC, commas are reserved characters. They are allowed for filenames in URLs. I haven't tried it, but you should be able to configure conversion of comma to dash (or other characters) in module InputfieldPageName to avoid them in the first place. Configurable option for convertEncoded in the InputfieldURL module also seems hacky to me.

I took @bcartier's code from this post and made a configurable module from it. EDIT: to make it work, you need to follow 2 steps (thanks to @PWaddict for pointing it out): Add a page name to the default language on the Home page On Languages Support - Page Names module at "Default language homepage URL is same as root URL?" select "No - Root URL performs a redirect to: /name/" You can find the module attached. I can confirm that the redirection to a non-default language works on PW 3.0.172 DefaultFrontendLanguage.zip

@fedeb what software did you use to create the performance graphs?

My repeater field's name is 'repeater'. So the template name of pages that this repeater creates in the background is 'repeater_repeater'. If my repeater field was named 'myrepeaterfield' then the template would be 'repeater_myrepeaterfield'. Repeater fields create one page for each repeater entry to store the data. Those pages are located in the page tree under Admin->Repeaters. In my case it looks like If you edit one of those pages, you can see the template name that PW creates automatically

@Bike already put you on the right track. I have an example setup that does just this: pull values from a repeater field and display them in a select dropdown. Here's how I made it work. 1. have a repeater field called 'repeater' on a template. The repeater field can have as many fields on it as you like. Mine only has one field named 'headline' 2. make some entries to that field 3. setup a page reference field, mine is named 'selectfromrepeater'. It has Single Page selected in Details tab. In the Input tab, I have following settings See the Label field? Here I have entered the field 'headline' from my repeater field. In your case you can enter 'link' or 'url' 5. I'm using the Custom PHP Code option to retrieve the selectable pages, so in my site/ready.php file I placed this hook: $wire->addHookAfter('InputfieldPage::getSelectablePages', function ($event) { if ($event->object->hasField == 'selectfromrepeater') { $event->return = $event->pages->find('template=repeater_repeater'); } }); Now when I add the new field 'selectfromrepeater' to a template and edit a page with that template, I get something like this: If you wanted to retrieve the selection via API in a template file, you would do $page->selectfromrepeater->headline // or ->url in your case Hope that helps

A workaround is defining the type in an @var comment like /** @var ProcessWire\MarkupAdminDataTable $table */ $table = $this->modules->get("MarkupAdminDataTable"); $table->headerRow($header); This will give you nice type hinting

Almost 2 years later and I am trying to tackle the same problem. $config->adminThumbOptions is still being referenced in https://github.com/processwire/processwire/blob/master/wire/modules/Inputfield/InputfieldImage/InputfieldImage.module In https://github.com/processwire/processwire/blob/d8945198f4a6a60dab23bd0462e8a6285369dcb9/wire/config.php#L755 it says width and height are deprecated in favor of gridSize. So it seems we cannot set a default admin thumb size anymore with width and height. BUT something weird is happening in a 3.0.65 install when I add this to config.php $config->adminThumbOptions = array( 'width' => 270, // max width of admin thumbnail or 0 for proportional to height (@deprecated, for legacy use) 'height' => 0 ); I have 2 image fields. One for single. the other for multiple images. After adding above setting, thumbnail creation for the multiple images field results in 270 width images. But only if I do a $myimage->width(270) directly after frontend upload. Even after reloading the page in admin, no extra variation is created. So far so good. BUT the single image field behaves differently. Through a hook I create a variation 270x0. But an additional variation 0x260 is created. This seems to follow the gridSize setting logic. So the behavior is different across 2 fields. Only difference in the field settings being that one is single, the other is multiple images. I would love to see consistent behavior here. And it would be super great to have full control over variations created automatically by PW. Imagine a use case where pages never will be opened in the admin, not even listed with pagelister. This is my scenario. And we will have about 25,000 pages created with 3 images each for that project under heavy server load with up to 3000 visitors at the same time. Of course we would like to keep storage requirements as lean as possible and optimize for performance. Meaning creating as few image variations as possible and only the ones we really need. Guess this is a rather rare use case for the time being. But still it would be awesome to have full control over the admin thumby thing. Especially since more and more devs seem to be using PW as a headless backend.

I was just about to ask for a release date, too :-) Seems I'm not the only one who is keen on getting their hands on this. As I understand it, this will be released as a paid module which is only fair. @flydev ?? mentioned that he wants to get the promoting website up and running before selling the module. Just in case that this is slowing things down, I would even be happy to pay for a pre-release version.

Thank you for this module! It was not working for me until I found out that the HTML created by CKEditor was something like <p style="margin-left:0cm; margin-right:0cm">https://www.youtube.com/watch?v=Lh63JcccM7k</p> So the <p> tag has a style attribute. The regex (line 180 in module php) does not cater for that. $regex = '#<p>\s*(https?://(?:www\.)?youtu(?:.be|be.com)+/(?:watch/?\?v=|v/)?([^\s&<\'"]+))(&[-_,.=&;a-zA-Z0-9]*)?.*?</p>#'; I adjusted it, so that it also works for paragraphs with attributes $regex = '#<p.*>\s*(https?://(?:www\.)?youtu(?:.be|be.com)+/(?:watch/?\?v=|v/)?([^\s&<\'"]+))(&[-_,.=&;a-zA-Z0-9]*)?.*?</p>#'; @Lex Sanchez maybe you want to implement this in your module.

Glad that this is still useful for you. In the meantime there have been quite a few posts about this topic and there is a great module out there that can assist in building REST APIs with ProcessWire: https://processwire.com/modules/rest-api/

Here is one possible way to go about this: add the user role and template name to the ProcessWire.config JS object with https://processwire.com/api/ref/config/js/ in /site/modules/InputfieldCKEditor/config.js retrieve that information and setup different CKEditor configs depending on role/template