wbmnfktr

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).

You're welcome! I wish I could help more.

I don't know if this could be the reason. I know that there is one project - I maintain - with a Cloudflare -> Nginx -> Apache setup. Maybe I'll find the time to play around with it on the weekend. For the moment... ¯\_(ツ)_/¯

Kind of... Works with some automation pretty nice and easy.

That's wild... why is there such a different behaviour? Nonetheless... it's working now. ?

Good advice. For the record: In my testing site namespace wasn't set. Just added it. Works the same. No difference.

3.0.140 works fine in this case. Just tested it here with wire404Exception(). PageNotFoundException() doesn't work - tested that as well. Can you please doublecheck $catPage. Maybe... I don't know... there is a glitch.

Ok... the hardest part seems to be stripping out/receiving all current database entries in order to migrate them in one way or another. Working remote on the server might work somehow but I would try to get a local copy. That's most often way easier to handle. The templates shouldn't be a problem either. At least it looks kind of easy and seems to be pretty normal. I actually don't know the structure of CodeIgniter projects but I guess you should find all necessary parts (HTML, CSS, JS) pretty easy. You might want to take a closer look into things like preprocessing (SCSS, Less, JS) and automation of some kind. Every developer uses his tools and quirks so there still might be some caveats ahead.

The 3.0.140 brought some issues with 3rd party modules and I try to avoid the DEV version at the moment for that reason. Therefore this was just a guess but maybe the DEV version also affects core features like this. Try the latest Master (3.0.123) if possible. If that's the fix we have found the suspect. By now your code snippet seems fine to me - at least the modified (other if statements and Wire404Exception) version works as expected here.

So... I just played with it a bit. Does NOT work: throw new PageNotFoundException(); Does Work: throw new Wire404Exception(); Tested it on a ProcessWire 3.0.133 installation. Are you maybe running the DEV 3.0.140 version?

You use PageNotFoundException() while I only know and see Wire404Exception() in examples. Does it make any difference? Additional sidenote: Very old (2010 and 2013) thread but still... interesting.

Have you seen this tutorial/guide? https://processwire.com/docs/front-end/how-to-use-url-segments/#best-practices