wbmnfktr

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

I get paid by the hours so... oh wait. ? Good to hear it worked for you! ?

Carefully and well planed. Parts of it could be migrated via API I guess and some parts need to changed manually. It all depends on several details we don't know, yet. Based on the details you provided... somewhere between a few days and a year. Plus the design part. How much books, movies, events, etc. need to be migrated? How many templates are needed? How ... ? What ... ? Who ... ? Hard to say actually. We don't know anything about the site, the data, the functionality. You should at least understand whats happening in the code itself. As you you didn't mention any eCommerce stuff or bookmarking or recommendation features there seems to be not that much of functionality in the code and therefore I guess it will be only be common template logic and maybe some data management. The hardest part will possibly be the content and data migration. As soon as those are in ProcessWire it should be a piece of cake.

Whenever I had issues with databases in Laragon I re-used a database name. Means... I deleted a database, created a new one with the exact same name and afterwards I ended up in things like that. Maybe it was the reason here as well.

At this point I'd like to open this issue to someone who is way more into hooks and custom functionality than I am. Maybe @bernhard or @adrian or @szabesz or @dragan ... they know a lot more about hooks and ProcessWire than I do. They will have a solution for this.