wbmnfktr

PWImage is enabled by default and the button itself is present by default as well. But it's only available in textarea fields and not text fields and you want to add an image field to your template as well. That makes things easier.

So you want to send a copy to the website visitor itself? Never tried it but... you can define additional recipients within the options and maybe even from within a hook. <?php $this->addHookBefore('SimpleContactForm::sendAdditionalMail', function(HookEvent $event) { $form = $event->arguments(0); $emailCopy = $form->get('scf_emailcopy'); // more logic here }); More details and another hook example at the bottom of the page: https://github.com/justb3a/processwire-simplecontactform

You wouldn't. Just use $image->description as it's the actual image which has a description. Your thumb and large variations or just that. Variations of the original image.

$content .= "<a href='$large->url' class='thumb-roll'> <img src='$thumb->url' alt='$image->description' /></a>"; How does your code before that part looks like? I guess you already tried $large->description and $thumb->description. Correct? Are descriptions set?

In a local environment like Laragon you have to enable mail-catcher or an external SMTP. In case of MAMP there may be similar settings. With a local Linux environment you most likely will need sendmail, msmtp or a similar setup. When this happens on a regular hosting plan your provider might have disabled this feature. I'd recommend a look at WireMail: SMTP as it uses an external SMTP server/mail account (which you define). I'd say it's the most reliable way to send emails from within ProcessWire. But that's just my opinion.

I loved doing that. Especially with my own projects. No matter how long they have been online. 2 years or 2 weeks. The slightest change and I started a rebuild. I try to stop this behaviour as it costs too much time. In case of a client project there is most of the time neither the money, nor the time for going this way. But... yeah, starting with a fresh copy is always great.

You will remember it the next time. ? I checked the multilanguage support... that worked as well. As said before... try taking it apart with just a few simple templates to find the real problem.

I tried this: fresh 3.0.123 installation multilanguage profile PHP 7.2 latest Pages2PDF module At first I saw no changes at all because I changed the wrong templates in /site/modules/Pages2PDF/default_templates/ and not those in /site/templates/pages2pdf/. Right now... all I can say is: it's working as expected. Sure... there is no custom code in my page templates or anythings. Just the basic stuff. My recommendation: try it with a simple basic template without anything else in it. Maybe even blindtext. Maybe the reason for your errors are at a different place than the module itself. Update: just saw in your post that you ARE in the wrong folder with the wrong templates.

Just to get the records straight... ProcessWire version? Multilanguage profile or another profile made multilanguage? How many languages? Does it work in any of the languages? PHP version? Module version? How do you generate the PDFs? Code snippet would be great Where do you create the PDFs - frontend or backend? Templates: page or PDF? Template location? Template strategy - delayed, direct, regions?

I maintain a 2.5 instance of ProcessWire which needs to be upgraded in the future, too. Not only ProcessWire itself but design and functionality as well. 1.) My first test-run showed me that several things changed. The biggest issue so far was a field called limit. It worked in that site but with 3.x it doesn't. Some names are not allowed anymore - or are already pre-defined somewhere but there are easy ways to avoid that. Just rename those fields before upgrading. Which brings us to the next point. 2.) Always use a test instance and have a working backup. ? 3.) Modules are a big roadblock. Some don't work anymore with 3.x, some just say they don't support 3.x and others just need to be updated. By now I downloaded the most recent version of all modules manually. Switched old modules for newer ones and changed the ProcessWire core at the same time. It worked pretty well - after hitting refresh a few times. ? 4.) Compiled files cache, markup cache, sessions... just drop them. At least that's what worked for me. 5.) Crawl the whole site after first upgrades to find 3xx, 4xx, 5xx issues - I use ScreamingFrog and the Jumplinks module. 6.) Namespace... I had to add it to some files. 7.) I created a site profile from my upgraded copy and tried to install it. Just to check if everythings works even after exporting it and such things. It worked. Luckily. So I had a first, clean. updated and working version of that project for the upcoming changes.

Just in case - don't activate the auto-accept option. Unless you modified the code to auto-disable cookies.

As you allow users to manage their decision/choice change one line in your module and it's done. notice.tpl.php - Line 18 <span class="pwcmb-widget__close js-pwcmb-manage-cookies">Close</span> Instead of accepting cookies the user has to choose now wether he allows or denies cookies.

You're welcome. ?

We could call it a marker of some kind. Yes. And everything around it. As said... install it and play around. There are tons of things you can change, edit and do with it. Depending on the tools, cookies and things you want to use, you might want to extend parts of the module with your logic and functions.

First things first. Look into your field settings if there is a (new) limit set and also check your php.info for these two option: upload_max_filesize = 20M post_max_size = 20M

Are all your modules up to date and compatible with ProcessWire 3.x? You can clear the compiled files cache - can be found at the bottom of your module page - and try again.

The module itself is more like a toolkit. It looks for a cookie to show/hide the banner and sets value(s) depending on the user's choice and your settings. Based on that decision and your settings you can build up your more complex logic if needed. if(localStorage.getItem('pwcmbAllowCookies') == 'y') Source: http://modules.processwire.com/modules/cookie-management-banner/ That snippet allows you to trigger/load Matomo, Google Analytics, Tag Manager, Amazon, whatever. Play around with the module and keep an eye on all the cookies/localStorage values and when they get set. So... coming back to your question: if the user neither allows, nor denies cookies the module does almost nothing. There is an option to autofire/allow cookies/track visitors but at the end you always decide what happens in which case. You could build something like this: https://github.com/webmanufaktur/CookieManagementBanner/blob/master/assets/html/CookieManagementBanner.OptInOut.html

Sounds like you could use LazyCron here. Check your pages how often you want (daily, weekly, each hour), look for those pages and do what ever you want to do with them. Put things like this in ready.php or create a module: <?php namespace ProcessWire; wire()->addHookAfter('LazyCron::every6Hours', function (HookEvent $e) { $pagesOlderThirtyDays = $e->pages->findMany("template=order, ... "); foreach ($pagesOlderThirtyDays as $potd) { // WHATEVER YOU WANT }; });

Just queried Google and there might be a problem with either ImageMagick Ghostscript Missing fonts Wrong/false/incomplete embedded fonts Other font issues Or in short... if it's a server-related you might have to dig quite deep into it. From ImageMagick versions to installed Ghostscript fonts to (above mentioned) policy restrictions. Depending on your hosting or the client's hosting it might not even work. Shared hosting plans don't allow access to files and folders - but in most cases those environments are pretty well configured. It might be easier to create a already pre-rendered first page for the PDF without any real text and fonts. Maybe converting them to paths or however it works in InDesign. As it is only a download and nothing you'd push to a print shop, it should work out just fine.

No umlauts in the cover/screenshot of your uploaded PDF? Do you use some special fonts in the PDF which are not embedded? I got the module working somehow and threw a ton of PDFs at it and there were lots of ä,ö,ü and ß.

It stopped working and/or changed its expected and known behaviour without any changes in the code itself, while keeping the exact same workflow? Check the CSV. The content in each field, the encoding, the first row/headers, everything. In Excel, LibreOffice, VS Code, Notepad, whatever. You, a colleague, someone not involved in programming/code/data management.

If those are regular pages you can just create another parent for the category pages, move them and the URL changes.

Just tested it locally in two different ProcessWire instances and it worked as expected. Used my admin user and I saw the images, was able to edit/delete them. ProcessWire 3.0.133 and 3.0.98. Can you actually view these images by taking their URLs? Maybe it's just a cache or browser glitch in the backend somehow. Are there 404 or other warnings in the console > network tab?

Can you post your selector query? What version of ProcessWire are you using? Is one of the pages hidden? Is there something special with your pages or templates? Are these pages not visible to guests or admin users or everyone?

Well... what's your setup? Laragon on Windows works perfectly fine without issues like that. MAMP on Mac in most cases as well - as far as I know. Managed servers (root, vServer, Cloud Server) should in most cases be fine as well. At least at good hosting companies. Local Debian/Ubuntu servers with a LAMP stack need only a few tweaks to work perfectly fine. So... depending on what you use you either want to ask your hosting company or login via SSH to enable mod_rewrite or look into your Laragon/MAMP config. Maybe you have to enable an option or two there (which I really doubt actually).