dragan

How does your PW site-structure look like? Does the parent / child structure match your desired URL structure? And I agree with @wbmnfktr - this kind of structure belongs to a dusty museum, and not a site built in 2019... Why do you need .html suffixes at all? Is it for legacy reasons? It feels wrong and cumbersome for so many reasons...

I was wondering why PW didn't automatically recognize that a new file has been uploaded to the assets folder (it's just the way PW works; as long as there is no entry in the DB, PW doesn't care what else is in that folder)... after a quick search I found this thread I added/replaced now the last couple of lines to: $path = "/home/mysite/www/dev.test/site/assets/files/$myOffer/$fn.pdf"; d($pdf->save($path)); $myOfferPage->of(false); $myOfferPage->files->add($path); $myOfferPage->save('files'); That way, site editors "automatically" see the generated PDF in the backend, and don't have to re-generate a new one each time.

Thanks. That works! I was playing around a bit more with it, and during that I managed to completely trash Tracy (it was gone all of a sudden), had massive problems with PW's file compiler and Tracy Cache, plus PHP memory limits and whatnot... Most probably not related to mPDF or RockPDF at all, I guess I was using wireRenderFile() wrong... Here's a little example (generates a 24-pages PDF with limited rights, meta-data, and custom font in approx. 3 seconds while in debug mode) <? @ini_set('memory_limit', '8192M'); // just to be on the safe side @set_time_limit(600); // ditto $pdf = $modules->get('RockPdf'); $pdf->settings([ 'mode' => 'utf-8', 'defaultheaderfontsize' => 9, 'defaultheaderfontstyle' => 'I', 'defaultheaderline' => 0, 'SHYlang' => 'de', // doesn't work 'hyphens' => 'auto', // doesn't work - I have this also in my CSS 'margin-top' => 20, // doesn't seem to work either, for some reason 'fontdata' => [ "inter" => [ 'R' => "Inter-Regular.ttf", 'B' => "Inter-Black.ttf", 'I' => "Inter-Italic.ttf", 'BI' => "Inter-BlackItalic.ttf", ]], 'default_font' => 'inter' ]); $pdf->set('SetHeader', 'Offerte Steuerrechner Kanton Zürich 2019, Test AG, ' . date('H:i:s')); $pdf->set('SetFooter', '{PAGENO}'); $pdf->set('SetTitle', 'Offerte Steuerrechner Kanton Zürich 2019'); $pdf->set('SetAuthor', 'Me Myself and I'); $pdf->set('SetCreator', 'Test AG'); $pdf->set('SetSubject', 'Offerte Steuerrechner'); $pdf->set('SetKeywords', 'Steuerrechner, Offerte, Angebot, Test AG, Frontend-Entwicklung'); $pdf->set('SetProtection', array('copy', 'print', 'print-highres')); $myOffer = 11568; // each offer has a parent page with meta-data, and "chapters" as children. We pass this to the template on the next line $str = wireRenderFile("/home/mysitecom/www/dev.test/site/templates/offer-index-dev.php", array("offer_index_page_id" => $myOffer)); $fn = $pages->get($myOffer)->name; // will be used to generate filename.pdf $pdf->write($str); d($pdf->save("/home/mysitecom/www/dev.test/site/assets/files/$myOffer/$fn.pdf")); // generate pdf in PW default file assets folder // in offer-index-dev.php, I have this at the top if(!isset($offer_index_page_id)) { return $this->halt(); exit(); } if(isset($offer_index_page_id)) { $offer_index = $pages->get($offer_index_page_id); } // I then use $offer_index->title etc. instead of $page->title further below Not exactly rocket science, but maybe somebody else can use bits of it as first baby-steps ?

@Robin S Thanks! I made two tests - everything works just fine now (didn't test yet with specifying templates using [[abc]], but no doubt that works as well)

Good thing is that PHP is so widespread, and hence, also well-documented. You should be able to quickly find a solution if a certain function behaves now different than before. There's plenty of migration guides - here's just one example: http://php.net/manual/en/migration70.php

Sorry to spoil the party... ? Well, I'm not sure what this is all about, but right after creating the set of pages mentioned above, I went ahead and created another set. This time, the uppermost ul parent was not created: instead I got only the direct child list pages (with correct child pages). I checked that there were no pagename collisions or similar: there were no pages with the same page name as the one I defined as the main ul page-title. I am using a multilanguage setup (although - only the title is textmultilang)... could this have to do with such inconsistencies? I also made sure there was no accidental p tag in-between. The first thing I did when CKE loaded, is click on the list-icon, and then only used the indent/outdent buttons from CKE, to avoid such pitfalls. I'll do some more tests and see if I can find a pattern here.

@Robin S Excellent! Works wonderfully now: Thanks for the swift fix!

@bernhard Servus Bernhard, I was playing around with RockPDF today... I was wondering if you maybe disabled some mPDF functions (intentionally or not)... I tried e.g. setting header styles or use hyphenation, but those don't seem to work. // either of these returns // Exception: Call to undefined method Mpdf\Mpdf::defaultheaderfontsize() on line: 50 in /home/mysite/www/dev.mysite/site/modules/RockPdf/RockPdf.module.php $pdf->defaultheaderfontsize=9; $pdf->defaultheaderfontstyle='I'; // same here: Exception: Call to undefined method Mpdf\Mpdf::SHYlang() $pdf->SHYlang = 'de'; These functions are straight from the official docs... oh, and btw: How do I adjust the default download path and filename? (using something else than "output.pdf") d'oh: $pdf->save('foo.pdf');

Sadly, this doesn't work quite as expected here... The first time I used it, every page was created in root. The second time child and grand-child pages were created correctly, but there's something odd with the page-titles it generated for every parent page: PW 3.0.125

I would simply backup the site and run it locally, e.g. with Laragon and a recent PHP version. Activate debug-mode in site/config.php, and test everything (backend and frontend). If there are PHP errors or warnings, it should be easy to fix them.

I would also add cursor: pointer; just for good measure...

@Karinne Cyphers Did you see my response in your earlier thread? I still wonder why that Pro Field doesn't work for you (or at least not for all instances). Hanna Codes could probably work for your scenario. I can imagine a very basic setup that should work with a repeater setup like: repeater_shortcode = string repeater_content = anything (rich-text, plain-text...) You could save all that in one "settings" page, hidden from frontend-view etc. And in your ready.php you'd define a hook-rule to check if any such shortcodes are present, and do a simple search+replace on those (of course, you would have to tell authors what pseudo-tag it has to be wrapped in: [[address]] or ::address:: or whatever...)

Sorry, I already have another question: Once I subscribe, I see the bell icon on every subsequent page. Is that intended? I would expect to see this icon just once. Wouldn't you expect to not see it again after you either click "yes, subscribe" or "no thanks"? When I publish my page, I get the following error: Session: SQLSTATE[HY093]: Invalid parameter number: mixed named and positional parameters Something weird is happening when I want to set "Schedule send time": The field always stays @ 2019-02-21 15:02:00, although I set it to 2019-02-21 15:55:00 (no matter if I set it via Date/Timepicker, or manually). It jumps back to this time after saving. Are any timezones hard-coded? The time is a couple of minutes in the future. If I set it to sometime in the next hour, the time saves correctly. o_O When I click on the notification (which appeared twice, by the way, stacked on top of each other), I get redirected to mysite.com/pw-backend/page/edit - and of course I see the login-screen there. I don't get redirected to my page with template pushalert.

Great stuff! Do you know if Pushalert only accepts the root of a site/domain? I have a test-site installed @ dev.domain.com/project-name/ When I enter the above URL, Pushalert just saves dev.domain.com/ That's probably why I don't see anything in the bottom right corner in my frontend: Edit: actually, it works - but only after I copy and pasted the JS myself in the HTML HEAD (module didn't insert anything).

I've never created any custom field types myself, but maybe this recent thread helps:

Did you try this? Either another remote server, or locally. Can you temporarily double that limit and see if that changes anything? (Drupal recommends this as the bare minimum, and Typo3's min. is 256M - I'm not comparing apples to oranges, but 128M in 2019 ain't really that much)

@LostKobrakai I wasn't first sure whether the OP was talking about performance in FE or BE (or both), so that part of my remarks was assuming FE (of course, a tpl/page in the FE with 100 fields will certainly be slower than a page with only 10 fields...)

For PW, that's really nothing. The number of fields, templates or pages is almost irrelevant when it comes to performance. It's mainly what you do with these that can have an impact, i.e. complexity. Do you have complex selectors running? Do you use repeaters excessively? And when you say "page rendering": frontend and backend? Or only one or the other? e.g. what is known to slow page rendering down, is when you have lots of richtext-fields in a page (page-edit view), and lots of repeater/repeater matrix and similar fields. The browser needs some time until all that JS is doing its thing and can start render the DOM... In such cases it's worth to fine-tune field-settings. I would try to copy the whole site somewhere else and compare speed. Maybe switch debug-mode off. Last, but certainly not least, use Tracy Debugger to analyze bottenecks.

.ProcessLogin #pw-content-body { text-align: center; }

I can't believe I've never used wireRenderFile before... So, it all works nicely so far, but I have a basic question: I am using the function in a parent page to render child pages. Child pages can have various types of templates. In my included file, when I use $page, it referes to the page calling the wireRenderFile function; fair enough, and logical. Is there a way to check in my included template file if this child page is called directly, or whether it has been included from somewhere else? A simple check, so I can use the template in both scenarios (stand-alone view for just this page, or in cases I use wireRenderFile somewhere else). Right now I am passing the child page's ID like this: wireRenderFile('my_template', array('pid' => $child->id)); And in my_template, to access it's own page fields, etc. I use $thisPage = pages()->get($pid); $myField = $thisPage->foo; // etc. Is that the way to go, or do I overlook something obvious? d'oh of course, it's as simple as: if(isset($pid)) { $thisPage = pages()->get($pid); // we get called with wireRenderFile } else { $thisPage = $page; // business as usual }

@Robin S Sorry for the late reply: Your solutions works perfectly. Thanks!

https://processwire.com/docs/start/install/troubleshooting/ I would delete my PW cookies, check allowedHosts in config if you switched domains, and delete the contents of site/assets/cache. Plus checking server and PW logs. Also, temporarily switch $config->debug to true to see errors you normally wouldn't see if set to false.

I was pleasantly surprised this module still works on the latest dev PW version ? Well, with one exception: The search assumes there are two more fields present, but the readme doesn't mention them. This results in errors... https://github.com/somatonic/ImagesManager/blob/master/ImagesManager.module#L469 Are select_production + select_person page-references? I can't find them in the install instruction or module config. (I'm fully aware the module has never been officially declared as stable and is now 5 1/2 years old, but some files have been updates 4 months ago, so I thought maybe asking here wouldn't hurt...)

I wonder if it is possible to customize the inputfield selector: It's working fine as is, but when you click on "matches the following pages", the modal shows columns which sometimes don't make sense (e.g. if I select template=basic_page, I get fields first_name + last_name). That was probably my column selection I made the last time I used the default Finder Lister. Are those stored in cookies or sessions? It would be nice to define preview-columns in the field instance itself, after the initial selector definition. Someone got an idea?

I didn't test these (possible) solutions, but you can either add something to the CKE configuration: https://docs-old.ckeditor.com/ckeditor_api/symbols/CKEDITOR.config.html#.entities_processNumerical or give this plugin a try: https://ckeditor.com/cke4/addon/specialchar