Leaderboard

When you enable device mode in the dev tools the user agent will change and therefore the fingerprint will change. I solve this when developing locally with the following in config.php: if(in_array($_SERVER['REMOTE_ADDR'], ['127.0.0.1', '::1'])) { $config->sessionFingerprint = false; } If you're working on a remote site and don't want to change the fingerprint settings then you can use an incognito window when viewing the front-end in device mode.

Hey @Thromisios welcome to the forum ? In my opinion: ProcessWire is perfect for this scenario! Why I think that: ProcessWire has a very active and friendly community that will always be there to help (that's very important when learning something new). I used other systems before ProcessWire and in their forum you never knew if you would get an answer or not. Terrible. In the PW forum you'll almost instantly get great answers or even ready to use code snippets or even modules ? ProcessWire hides a lot of complexity in the beginning. That makes it easy to use and you can come very far by using a few very basic concepts. Often it's just using fields together with the API. On the other hand ProcessWire is capable of so much more. That's all hidden under the hood and once you grow, you can start exploring more and more of it's features. In other systems you'll have to learn a lot upfront just to get simple things done. For example with other PHP frameworks you'd have to build the admin interface for your users completely from scratch (not all systems of course, but there are many where you have to do so). Hooks are such a brilliant concept that not every system has. Most of the time when you want a small customization of your system/program/website that means a small snippet of code. In other systems you often need to understand the whole OOP model to extend the correct class or you need to build a plugin or an extension. In ProcessWire you hook into the correct spot (if you don't find that the forum will help) and you add some simple lines of PHP and you get what you want. We have Adrian's great TracyDebugger which is such a huge help while developing. Just a simple dump of a variable is so much more helpful than doing a var_dump(). Other systems might have similar tools, but there are for sure systems that don't have anything like that. For me it was an eye opener in many cases. For the last part you can head over to my signature link "afraid of hooks?" A simple example could be: <?php // send me an email when the client adds a new blog post $wire->addHookAfter("Pages::added", function($event) { $page = $event->arguments(0); // only execute this hook for pages of type "blog-post" if($page->template != 'blog-post') return; // send mail $mail = new WireMail(); $mail->to('your@mail.com'); $mail->from('robot@yoursite.com'); $mail->subject('New blog post at yoursite.com'); $mail->bodyHTML("Url of the new post: ".$page->httpUrl()); $mail->send(); }); Good luck and have fun ?

Hi @Thromisios Welcome to the PorcessWire community. I came from non coder background, too. I first started learning ProcessWire basics by following this tutorial. Gideon

Hi, I know quite a few of us are working on multi-language websites and are most likely using the `strftime`, however it's deprecated as of 8.1.0 and set to be removed in 9.0. There's some time left but on my local environment using MAMP and 8.0.8, it's as if it's already gone as dates were not localized anymore. Looking for options, I came accross this which might be useful to others: https://gist.github.com/bohwaz/42fc223031e2b2dd2585aab159a20f30 What's your take on this ? Also I wonder how things will be handled in PW's core as the WireDateTime is using that function as well.

@kongondo sorry to bother with another bug report. On product-details i can not add properties in latest version. The search just wont start (i also see no activity in networks-tab in case it is ajax, the console also does not contain any js-errors) The properties and dimensions are created and published.

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' );

Brilliant. Thanks! I had a feeling something like that was going on. I usually use incognito when testing anyway - not sure why I didn't this time. That's a very practical reason for doing so. ?

Hello @chrizz, just wondering why would like to add "www" to the staging url? Thats seems very unnecessary. Instead of adding the $config->httpHost you could try to use $page->httpUrl: $form->action = $page->httpUrl; But including the full url for the form action is also unnecessary in my opinion. It should work with just using $page->url. I think it would be better to decide for just one host. As far as I know $config->httpHost chooses the closest matching host. So in your case staging.website.de seems to be a closer match on your server than www.staging.website.de. I would just not use "www" for the staging url and use a relative url for the form action. ? Regards, Andreas

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 now get what you meant. I think the bug #1 below is what you meant? This has now been fixed. Thanks for reporting. This is what confused me. I thought you meant you were able to add but not to search for dimensions. My mistake. It's all fixed now, thanks.

Thank you very much @Andy! will do so!

Hello @Thromisios First, I would refer you to the ProcessWire documentation - https://processwire.com/docs/start/ And then, look through the sections of the forum: https://processwire.com/talk/forum/8-getting-started/ https://processwire.com/talk/forum/13-tutorials/ https://processwire.com/talk/forum/6-faqs/ Next, I would look at the sections of the forum and documentation that raise more questions for me. And of course https://www.php.net/ when you don't understand how PHP works. Good luck with your adventures.

Hey all. I have read a bit through all the posts here, got inspired and have changed my personal little local tool for live reloading from using ajax polling to use SSE. If you like, I can share my experiences and thoughts to some of the (somewhere) above mentioned problems. My setup is manually enabling / disabling SSE via a button. The SSE-php file does NOT use PWs system. It is complet solely, means it does not use (and maybe block) a users PW session. It uses the basic examples from MDN, as the JS do too. No special buffering, string_padding or the like is needed! I use h2 (HTTP2) protocol, what also needs https to run. (I'm not sure, but I think h2 is needed for not early disconnecting (and then start polling)). My polling loop on the server is every second. I send one keep-alive ping around every 15 to 20 seconds. In the one-second-server-loop I check if something has changed in the GIT tree, in comparison to the previous run. If so, I do an ajax call to PW, where my styles and scripts pre- and post processors are hosted (in a module). (It is similar then included in ProCache, but was coded earlier then that in PC.) They do a in-depth check and do recompile necessary files on demand and return if refresh is needed or not, what, only if true, gets pushed through to the client browser. I can work in the admin, I can work in the client, also with concurrent fetch/ajax calls while SSE is listening, etc. My PHP file is: My JS in browser is: Here is a screen, showing the network tab and console:

@ryan Hey Ryan, this thread has definitely not gone the way I intended. I didn't mean to disrespect you or your work or to offend you, but I obviously have, for that I'm sorry. Thanks for still taking the time to address my points in detail. I agree that my tone was off and I was a bit too flippant, leaving the impression that I just want to advertise Craft and dunk on PW. I don't want to convince people to use Craft, I have nothing to gain from this. This is why I posted this in dev talk where I think most people reading this post will be long-time users of ProcessWire who won't jump ship at the first mention of another CMS. This is also why I didn't bother to write out a list of everything that's great about ProcessWire (for the record, that's a long list!), because I think most people reading this already use and like ProcessWire and don't need to be convinced that it's great. The fact that a free CMS developed mostly by one person can be compared to a commercial system developed by a team in this way and hold its own at all is actually impressive! I like ProcessWire, I've used it for years and still am. And I think I have contributed to PW a fair bit; I've pitched PW to dozens of clients and made sure the agency I work for buys the bulk licenses for most Pro modules. I've been active in the forum, I've written multiple open-source modules and an entire website dedicated to telling people about PW and how to use it well. I thought all this afforded me a bit of good faith when I'm writing something critical. Obviously I was wrong. I just wanted to talk about some things that I found lacking in ProcessWire and where I thought Craft has a good solution that PW could benefit from. Admittedly, calling this a comparison was a bad idea and gave the wrong impression. It's definitely not a full comparison in this sense, it's list of good ideas and approaches that I liked in Craft and would love to see in ProcessWire. At the very least it was supposed to. I'll try to address a couple of specifics below. For most of the talking points, I think your objections are valid and you're either right or there's arguments for both sides. I will leave out the points where I feel there's nothing more to be said for either site, or it's solely a matter of preference. Honestly, at this point I feel this discussion is way more heated than the topic warranted, probably due to me missing the correct tone or making some way too sweeping statements. If you feel this post is in bad taste or in bad faith, feel free to delete this thread altogether. You're right and I'm sorry about that wording. I didn't mean to imply that you didn't put a lot of thought and hard work into those features. What I meant to say was that some features don't work in particular use-cases which were important to me and that I don't think are super unusual or niche. In those cases, this use case was either not intended or not considered. And in those cases, the comparison to other systems (like Craft) has merit, if a similar feature is build in a different way that does enable those use-cases or is generally more flexible. This applies, for example, to the translation system. It's based on file scanning, so I can't use it at all since all my projects use Twig for templating and translations in Twig aren't picked up by it. So in this case, the translation system wasn't built to support any use-cases beyond the normal PHP templating. A different design for this feature, for example separating the file scanning from the translation API and allowing developers to call the API to add translations from their own code, would have solved this and enabled more use-cases beyond the one that the feature was built for. The relaunched processwire.com website, at the time this post was made, had major accessibility concerns. And at a very basic level at that, starting with the primary color used for backgrounds which doesn't provide enough contrast against the white text. I haven't checked everything, but as far as I can tell those haven't been fixed. This is a very basic accessibility issue, so relaunching a website like that signals that accessibility isn't important to this project. Of course it's only the website and not the CMS itself, but public perception matters to. I was referring to this quote in particular: To me, this demonstrates a lack of understanding of accessibility issues and goals. So I don't think I'm wrong in saying that good accessibility isn't, right now, a strong focus of ProcessWire. Agree, that was worded way to strongly. What I meant here is that the architecture imposes limits on the extensibility and in this case, you didn't seem willing to rethink the architecture to enable use-cases that go beyond the regular interface provided by ProcessWire. I still think this issue can be solved without compromising security or anything, by decoupling the logic for security checks from the CMS routes. I argued for that in the issue and haven't gotten a reply for over half a year now. To be, this signals that extending PW user accounts in this way is disouraged and shouldn't be done. Again, though, you're right that my statement here was way too sweeping. I'm also addressing the next couple of points here. The problem is that it's very easy to shoot yourself in the foot. In fact it's trivial to create an injection vulnerabilty: $category = $input->get('category'); $newsWithCategory = $pages->get("template=news, category=$category"); Of course I can sanitize the category input to make it safe-ish, but I have to remember to do that every time and it's easy to get wrong. This is why we use prepared statements instead of string concatenation for database queries with user input, to separate data from commands. So in this regard, the string-based selectors feel like a step back to me. That's fair. My point is that the interface is very close to implementation details, translations are grouped by the file they're located in. For clients who don't understand or care about those details - for example, that don't know anything about the template structure or indeed that there are templates at all - it's harder to use than it needs to be. What I mean is that the German translations might be stored in something like site/assets/files/10942 and to find that number I have to go to the backend and check. I can't just hit CMD+P in my editor, type in 'german' and get the appropriately named translation file immediately. I meant typing in translations in the code editor, see the point above. As far as I can tell, the language alternate fields are the only way to make fields translatable that don't come with a multi language variant. Like asset fields. If I want to allow an editor to provide a different image in the same asset field in multiple language, is this possible without language alternate fields? Last time I tried this I didn't find anything. Correct me if I'm wrong. The lack of documentation is a big thing. If I have to do some Google woodoo to find a blog post or forum thread from 2019 to figure out how something works, it's not well supported in my opinion.

Some of you might of used my previous U2F module for their two factor needs. Well I was recently informed that Chrome is dropping plain U2F support in favour of WebAuthn. So after a full day of debugging some cryptic errors I am proud to announce a WebAuthn module. This has some major improvements. For example you can now use on-device credentials like Windows Hello/Apple Touch ID. This means that even people without a Yubikey can benefit from modern two factor authentication. It also has much better cross platform support. For example NFC will now work on an iPhone. I do not recall the original U2F stuff working well on iPhones so yay? The is still the original issue that ProcessWire imposes with its Tfa class, That being it is a setup once and never edit again system so you can only add your on-device credentials for a single device because once saved you cant then edit your credentials on a second device. You also lack the options to revoke a single credential or add a new one. You have to wipe out the config and re-add your keys again. It sucks but realisticly if you need more than 3x credentials your almost defeating the point of Tfa I feel the need to also point out that this does not replace passwords. That is something WebAuthn can do a fully passwordless setup. But I think implementing that inside ProcessWire would be a huge challenge. It is frankly a form of magic that I was able to make WebAuthn work within the confides of ProcessWire's Tfa class. Github: https://github.com/adamxp12/TfaWebAuthn ProcessWire Modules: https://processwire.com/modules/tfa-web-authn/ I hope this module helps you guys out securing your ProcessWire websites If you have any issues just reply and I will do my best to help you out

i do this sort of thing now a lot, thanks to Ryan's CMS Critic Case Study; this is almost the same as WillyC's code at the above link /** * This hook modifies the default behavior of the Page::path function (and thereby Page::url) * * The primary purpose is to redefine blog posts to be accessed at a URL off the root level * rather than under /posts/ (where they actually live). * */ wire()->addHookBefore('Page::path', function($event) { $page = $event->object; if($page->template == 'post') { // ensure that pages with template 'post' live off the root rather than '/posts/' $event->replace = true; $event->return = "/$page->name/"; } });

Dave, You can add whatever fields you want to the user template. I'm building a fairly complex user profile setup as well. Go to: Setup > Templates, at the top of the page open the "filters" area and enable "show system templates". Now you can add any of your fields to the user template.