Stefanowitsch

Thanks! But this does not work unfortunately... However formatting the date like this was the workaround for me: date("d.m.Y", $termin->startdatum)

I found the reason: https://www.php.net/manual/en/datetime.construct.php The $timezone parameter and the current timezone are ignored when the $datetime parameter either is a UNIX timestamp (e.g. @946684800) or specifies a timezone (e.g. 2010-01-28T15:00:00+02:00). So thats why i get the wrong date when using this code here (my timezone gets ignored) <? echo IntlDateFormatter::formatObject( new DateTime('@' . strtotime($page->testdate)), "dd. MMM", 'de_DE' ); ?> Even when explicitly setting the timezone inside the DateTime object constructor it gets ignored.

I am bootstrapping processwire in a php file for cronjob purposes. Everything works fine, I can output all the data from fields that I like. What confuses me: I have a datetime field. When displaying the field value in the bootstrapped file, I only get the timestamp of the selected date. When displaying the same field value on a page inside of processwire the field value is a formatted date. Can somebody explain to me why this is the case and to get around this (without date formatting).

My config.php looks like this: $config->timezone = 'Europe/Berlin'; setlocale(LC_ALL, 'de_DE.utf8', 'de_DE'); I edited the json file in the Backend (with: de_DE.UTF-8). The timestamp looks like this: 1654898400 When examining this timestamp I get both dates: GMT: Friday, 10. June 2022 22:00:00 Your time zone: Samstag, 11. Juni 2022 00:00:00 GMT+02:00 DST It seems that I just ignored that fact that there are two dates shown (always look at the first one). My $page->testdate field outputs the date like this: 11.06.2022 So this outputs the right date (11. Juni): <?= strftime("%e. %B", strtotime($page->testdate)); ?> My problem is that this is deprecated in the future and the new way to do this looks like this: <? echo IntlDateFormatter::formatObject( new DateTime($page->testdate), "dd. MMM", 'de_DE'); ?> This also outputs 11. Juni (correct) But when using the timestamp I get the wrong date: <? echo IntlDateFormatter::formatObject( new DateTime('@' . strtotime($page->testdate)), "dd. MMM", 'de_DE' ); ?> This outputs 10. Juni

I was upgrading some date formatting code lines in my projects and noticed a strange behaviour. I have a date field in the backend which is a classic processwire datetime field. In this field I can set - for example - an event date. For date selecting I am using the HTML5 Datepicker option in the field settings. Besides that I changed none of the fields settings at all. To display this date in the frontend all i do is: echo §page->event_date; However - I need to format this date in multiple ways throughout the whole site. So I need a unix timestamp (for localization of the date). strtotime($page->event_date); When I check the timestamp that comes out - it is always exactly 1 day before the date that was set in the date field. So when selecting "08.06.22" in the date field, the timestamp says "07.06.22" When I format the date -based on the timestamp- to make it human-readable again I can confirm that the new date is one day in the past... How is this possible?

So i tried the other way around and formatted a date using the IntlDateFormatter. This thread helped me find my way: https://stackoverflow.com/questions/71874030/local-language-without-strftime-deprecated-but-with-date So imagine we want to output "today" like this (formatted for german) Mittwoch 8 Juni 2022 This was the old way to to it: echo strftime('%A %e %B %Y', strtotime('now')); Since this will be deprecated in PHP 8.1 and removed in PHP 9 now we have to make use of this instead: $fmt = new IntlDateFormatter('de_DE', IntlDateFormatter::FULL, IntlDateFormatter::FULL ); $fmt->setPattern('EEEE d LLLL yyyy'); echo $fmt->format(strtotime("now")); The only thing that freaked my out about this was the weird formatting pattern. At first sight it makes no sense (to me), but the ICU documentation offers a big list of available options for formatting the date in any way you could imagine: https://unicode-org.github.io/icu/userguide/format_parse/datetime/ If you are looking for a "one liner solution" then this seems to be the right way (https://stackoverflow.com/questions/12038558/php-timestamp-into-datetime) echo IntlDateFormatter::formatObject( new DateTime('@' . strtotime("now")), "EEEE d LLLL yyyy", 'de_DE' ); EDIT: Beware that timezone settings get ignored when you work with timestamps. This might get you into some trouble. My solution was to format the timestamp into a date string: echo IntlDateFormatter::formatObject( new DateTime(date("d.m.Y", $timestamp)), "EEEE d LLLL yyyy", 'de_DE' );

I have no take on this (yet!) but since I am using the strftime function a lot I better get used to a solution for the future. The library you postet here https://github.com/alphp/strftime looks promising enough, the "old" strftime code needs to be altered just with the locale and it works good for me: <?= strftime('%e. %B', strtotime('now'), 'de_DE'); ?> The "offical" solution seems to use the IntlDateFormatter::format, but I find the usage is nowhere as straight forward as with strftime... https://www.php.net/manual/en/intldateformatter.format.php

I was in the need for using this module together with background images too - but in the "classic" way without any components. I am using the famous Lazysizes JS Plugin for lazyloading the images. To create responsive background images with the PageImageSouce module I also included the lazysizes bgset extension So the code in my template file looks like this: <div class="img-title-wrapper lazyload" data-sizes="auto" data-bgset="<?php echo $image->size($imgFormat)->srcset() ?>"> /* your content */ </div> The wrapper element then gets it's height either via CSS (height: 100vh for a big introduction title image) or through the elements inside the container. Adjust the background image styles to your needs (e.g. background-size:cover).

Ah okay. I do not use the ProField Modules. That's a really cool feature, though.

Really cool design! I love the content module solution. I build something like that my own by using nested repeater fields... but can you tell me how you realized that good looking "Select type to add..." popup?

Most of the time its the smallest things that cause the biggest problems when going "live" with a site ? That is the usual way I do it (and I think most of developers do): 1. Export your local database 2. Create a new (empty) database on your live server and import the database there 3. Upload all project data from your local directory to the live server via FTP 4. Adjust the config files for the new database connection 5. Testing with debug mode enabled

That is a classic error message that I get all the time: The Database connection cant be established. Mostly because I forgot one of the things: - Do you have a variable in your config to switch between two development environments (local/live)? So that you are still trying to use your local database settings on your live site? - Do you already have a working PW installation on the remote server? Try checking the config values against the config that refuses the connection

Take your time! I am nut in a hurry. The project I am using this module on is still in development.

5.7.32. My Processwire runs on PHP 7.4.12

phpMyAdmin 4.9.7 It's a mySQL Database with a utf8_general_ci collation.

I read the posts on the previous pages, it seems that more people have trouble with upgrading the module. I will stick to the module as it is now. On the live site it runs fine and that is where the statistics do matter.

Sorry about that! Yes these messages are not error messages. But when you open a page and see a few hundred warnings you can get a bit nervous ? On my live site I don't get these messages at all, despite the debug mode set to off. So only my local environment causes the issue when there is no IP address assigned to my virtual host. Thanks for the fast help! I tried to upgrade via the PW upgrades module but this time I got a real error message: Modules: Error upgrading module (ProcessPageViewStat): SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'IF NOT EXISTS usr int(10) unsigned' at line 1

Hello! I installed the module and it works fine for me. But my local dev environment I get a ton of error messages - when not logged in - Warning: unpack(): Type V: not enough input, need 4, have 0 in /Users/sthumann/Sites/kibis/site/modules/ProcessPageViewStat/func/IP2Location.php on line 1013 This message repeats itself a hundred times, then at the end there are these two lines: Notice: Trying to access array offset on value of type bool in /Users/sthumann/Sites/kibis/site/modules/ProcessPageViewStat/ProcessPageViewStat.module on line 407 Notice: Trying to access array offset on value of type bool in /Users/sthumann/Sites/kibis/site/modules/ProcessPageViewStat/ProcessPageViewStat.module on line 408 In the modules settings I disabled all options. These error messages only appear when: - not logged in (on local dev environment) - when my local host has not an IP address assigned to it. I am using MAMP Pro on Mac... On the live site these messages never appear. I guess the that the IP2Location throws those errors when there is "no ip address" to find. So my question is if there is a way to detect if the page runs on a local test system to disable the tracking functions in those cases?

Great news! I was busy with other projects so I could not participate on the beta testing but I surely can't wait to give this new version a shot in one of my next projects.

Okay this solution is a little bit over-the-top for me. But the IntersectionObserver Function looks quite interesting. I've never heard of that before. In fact all my hand made "is element in viewport?" solutions were always kind of tricky to pull off.

I really like the clean look and the choice of color. The pink hue really gives a warm touch. And I absolutely like sites with big colorful images. What plugin was used for the image translation effects? Looks super smooth.

This seems to be a pretty useful module. I am looking for a solution just like that. Is anybody using this module with the latest Version of processwire and does it still work with the modifications mentioned a few posts above?

I was able to solve the problem. After logging into the backend and getting the blank admin page I discovered a log entry inside the tracy debugger log. There was an issue in my /site/ready.php file that threw an error: PHP Warning: Cannot modify header information - headers already sent by That error was caused by some spaces behind the closing ?> Tag inside the ready.php. I am using this same ready.php file on multiple other websites and it never made me any trouble though. I find the fact weird that this error is only provoked when trying to log into the backend. Anyhow I am glad that this is solved now.

So finally I uploaded the website into my own personal webspace to see if the login works - it does. So I guess it is some kind of .htaccess or php.ini (black) magic that is missing on the strato.de server. I am looking forward to see if somebody has a clue about this. ?

Another thing I discovered is that the redirect to the "URL with Slash at the end" does not work for the back-end login. For all other pages in the frontend it does. When calling: https://www.mysite.com/processwire I get a blank page. In that case you normally get redirected to the same URL but with a slash at the end: https://www.mysite.com/processwire/ This URL shows the login page. But after logging in I get a new blank page... In my local dev environment everything is working fine and I never had this problem before on other hosting providers.