bernhard

Thx @matjazp maybe it has to do something with locale settings? Not sure, but I really just did the steps outlined in the github issue. No external modules (only processdatabasebackups to share the sql file)...

Interesting find. Though I'd ask you to try that again, because my issue is from 2019 so it should not have been introduced between .190 and .197 as they are a lot younger! I just checked replacing the wire folder from my example setup... 3.0.184 --> same bug 3.0.96 from 2018 --> same bug

Thx @Klenkes maybe you can try my submitted version?

I've created this issue back in 2019: https://github.com/processwire/processwire-issues/issues/916 Ryan seems not to be able to reproduce the issue ? Can you guys please try what I show here and see if that works for you or if you get the same issue like I do? Video: https://calip.io/O1wKadGz#cQZ1CRZf Here is a copy of that site for everybody to install: https://github.com/processwire/processwire-issues/issues/916#issuecomment-1120170931 Thanks for your help! @matjazp are you even not able to reproduce the issue with my copy?

@horst the password could be encrypted using the $config->userAuthSalt. For sending an email the module could load the encrypted password from the DB, decrypt it using the config salt and log into the mail account. That way an attacker would have to have access both to the DB and to your config.php file. https://stackoverflow.com/questions/9262109/simplest-two-way-encryption-using-php Though I don't know if it's really worth having that extra...

If you are new to hooks the linked post in my signature might be helpful ? https://processwire.com/talk/topic/18037-2-date-fields-how-to-ensure-the-second-date-is-higher/?do=findComment&comment=158164

If you are working with CSV, don't forget about the new $files->getCSV() ? while($row = $files->getCSV('/path/to/foods.csv')) { echo "Food: $row[Food] "; echo "Type: $row[Type] "; echo "Color: $row[Color] "; } https://processwire.com/talk/topic/26929-pw-30197-– core-updates/

Hi @Luigi does ->filename work?

Actually it's a lot easier! // /path/to/pw/root/standalone.php <?php namespace ProcessWire; require "wire/core/ProcessWire.php"; $data = new WireData(); $data->foo = 'foo'; $data->bar = 'bar'; echo print_r($data->getArray()); // execute the script cd /path/to/pw/root php standalone.php How great is that? ?

Yes, if you want to dump directly (like echo), then d() is what you are looking for. But you can also use bd() to dump everything in the debug bar (bottom right). That's especially handy in ajax calls and such.

Maybe not a solution to your problems, but have you already tried https://processwire.com/modules/tracy-debugger/ ? I think it does what you are looking for and so much more ?

Hi @ttbb welcome to PW and the community ? one solution would be to enable url segments on the template of /artworks page. https://processwire.com/docs/front-end/how-to-use-url-segments/ That means you'd have an url like /artworks/[artist]/[artwork] and you'd have the artist in $input->urlSegment1 and the artwork in $input->urlSegment2 Does that help?

Yes. This has annoyed me several times. Not sure why I did not think of disabling session fingerprinting in my local dev config... $config->sessionFingerprint = false; ?

I saw the code, but I in the way that I understood the whole problem this should not work, that's why I asked how that worked. How do you execute your hnDevTools-SSE-LiveReloader.php ? From the command line?

The error message shows that you are trying to create a new Instance of CAPTCHA but in the ProcessWire namespace. This is because you have something like this at the top of your file: <?php namespace ProcessWire; Simply adding a \ should fix this error: $cap = new \CAPTCHA();

Cool ? Thx for sharing that @horst this sounds exciting! How does that work?

Did you enable all the noise blocking rules in htaccess? https://github.com/processwire/processwire/blob/5094a8ce8eb553ef2cf5a1c928fef647a2fbd075/htaccess.txt#L246:L294 I have no experience with it but it sounds like an easy and good thing to do? https://weekly.pw/issue/315/#latest-core-updates-processwire-3.0.157

Is anybody of you using the SystemNotifications module and also suffering from a lot of more or less useless notifications that are - and that's the main problem - persistent and not collapsible at once? Here it's 48 notifications that I'd have to click away each at once... In english those messages mean "compiled file... and user logged in: ..."

Definitely yes ? At the moment no, but I plan to create a video that shows the most important parts. The ProcessWire snippets are available here: https://marketplace.visualstudio.com/items?itemName=baumrock.pwsnippets (also on github of course), but the RockMigration snippets are at the moment only locally available until I've used them a little more. Thx for that feedback. That's absolutely understandable and a valid point ? Update 2023: I've improved a lot here and try my best to not introduce any breaking changes. My modules follow semantic versioning, so a major version bump indicates a breaking change so that everybody is aware and can check if that is a problem in his/her specific situation. Also there is the rock-monthly newsletter now to communicate the most important news.

Basically this was just a proof of concept to show that I could easily add a feature like this to RockMigrations and that this should in my opinion not be the point of the discussion... It was also there to show that it is just another way of making it easier for beginners to see a list of all the necessary or available properties of a field or template etc., but more on that later. Because? It does seem to be very interactive and maybe that causes problems. With ProcessDbMigrate I very much opted for batch creation of entity specs, which is easier to manage. Because - as far as I understood - the way it works makes it impossible to build reusable components which is a crucial part of being more productive and also increase quality. If you store migrations in a central place you lock the usefulness of that migration to the project. If you make it possible to store migrations where they logically belong (eg in a PHP class - or in the PW world in a custom page class), then you can create reusable components that you can move from project to project. Is that more complicated? Yes. Do you have to do that? No! You don't have to build modules and you don't have to write migrations in a component-based way. If you don't care you can simply put everything in /site/migrate.php This quotation is incorrect and unfair. If we are talking about this paragraph? I was just demonstrating here that there ARE situations where doing things by hand is slower. I've never said that using RM is quicker all the time. I have to lookup things myself now and then. My point is that if you take the whole picture into account this equation changes (as in this example doing the same changes somewhere else - either in a team or on another setup). That part is half unfair and half ok. The part that is ok is that I care more about my needs than I care about the needs of others. I hope you can understand that I am not keen on building a GUI based migrations tool when I know that I will not need it myself? Actually I do care about this much more than I should, but that's another topic... The unfair part is that I DO know how it feels to be overwhelmed by all this migrations stuff. I have been there when I first saw Lostkobrakais migrations module and I've had the same feelings (I guess) when he said "once you get used to it you'll be quicker writing code than doing things by hand". And I've heard the same last week when trying to understand the **** CMS where the core dev's show the product and nothing is as easy as they call it... And I've already taken the "feedback" and made the new version of RockMigrations MUCH easier to use and much easier to get started. Fine. Let's do that. I'm not against it. My point is that RockMigrations can serve both needs but with your approach I don't see a way to do this. So it's a little hard for me to read all those discussions and ideas and see (guess) where they would (could) lead to because I've been there... I understand these concerns. They are easy to solve: Your IDE gives you a dropdown as well - in VSCode its CMD+P (or similar on Windows): Most fields will just work with only the "type" attribute. For others I've started to build snippets as this is an issue that I have myself (so much for the topic putting myself into the shoes of less capable - I'm not better than you ? ? While the gif above shows that this is just another wrong statement based on false assumptions I want to add two more things. It's definitely not easy to remember all the properties of a field or of a template. But you don't have to! What if you wanted to change this field of a template? First option: TracyDebugger (works always): If that is too complicated there's also another option most of the time: And finally: Can I imagine that not everybody knows that? Yes. Why is that not in the readme? You'll get a similar answer to Ryan's related to the PW docs: I'm working on that alone. I'm not getting paid for anything here. And - and that's a huge difference to PW - I don't even know if anybody cares about migrations or RockMigrations in general. For a long time I thought nobody cares. But those threads show me that a lot of people actually do care about those topics. But still they seem to know nothing about RockMigrations. It's as if I'd create a thread "E-Commerce Wishlist for ProcessWire" without mentioning @apeisa or @kongondo 's Padloper and without doing my homework to research what their module does, where it has limitations, asking why they built it the way they built it etc... If that had happened the whole discussion would have been on a totally different level (at least for me) and the several arguments that have been correct (like for example the fact that PW stores language files in /site/assets/files) could have been communicated to @ryan and I'm sure he'd have been supportive to do whatever he can to make the core serve our needs (even if he does not yet have a migration/git based workflow). Amen ? And finally to quote @Robin S from the other thread because I created the video initially for you @MarkE before you wrote your follow-up: It seems like this should be doable via a module in PW. I have a work-in-progress module that does something like this. It's not complete and haven't looked at it a while but it seemed like a promising avenue at the time. I think if the concept could be illustrated in a module then Ryan might see the benefits and then hopefully incorporate the features into the core. Well yes, that's also very easy to achieve with RockMigrations.

Thx @MarkE I appreciate that! I'll need more time for an elaborate answer, but I have one quick point and one quick question: I think the point is not so much if RM has evolved or not. It's more about getting used to a new concept. The same would be true for your module even if there is a UI (which might make it easier, I agree). But still it's more time consuming in the beginning compared to working the way one has always been working... Did you see this post? https://processwire.com/talk/topic/26565-share-your-pw-dev-setups-tools/?do=findComment&comment=220542 It took me around 20min to implement that. I'm still not a fan of this approach. Even more, I don't think that it will work. At least not for more complex projects and that's exactly the kind of projects where migrations come into play and what RockMigrations was built for... But - and that seemed to be ignored / not understood / stated wrong in several situations - RM does not have to be used in that "complicated" way. You have to write "code", yes. Actually it's php arrays of key-value-pairs... But I can understand that this might look complicated... I just got an idea ? Before I answer the other parts... As many of those points have already been discussed. Did you see all my comments here? https://processwire.com/talk/topic/26565-share-your-pw-dev-setups-tools/?do=findComment&comment=220484

I'd vote for Method 3: A custom DB table ?? Sorry but giving an elaborate answer here is very difficult and depends on so many things. So my recommendation above is just to give you an idea of another option that might be good to think of. Having JSON can also be a good option, especially if your DB setup supports it: https://dev.mysql.com/doc/refman/8.0/en/json.html

Thx for your post @MarkE and sorry for not mentioning your module in the other thread ? Absolutely. 1) Could you (both) please explain what you mean by "declarative config". In detail. 2) Could you please explain what you mean by "RockMigrations is not really declarative". (Connected to 1) 3) Could you please explain why you think "RockMigrations is difficult to implement on existing sites". 4) Could you please explain why you think "it is fine if you want to code rather than use the PW Admin UI (*) and if you are doing everything the 'RockMigrations way' from scratch for a site, but I think it sits a little uncomfortably with the PW way of doing things." *) I can somewhat agree on that until here (though that's the whole point of the topic: Having the setup/config in files, not in mouseclicks...) but the rest could not be further from the truth. Sorry. That's why I think the discussion was not really helpful. It was full of opinionated assumptions and expectations without any noticable efforts in doing research in what we already have (and we have tools for that since 2016!), which concepts of the available tools work well, which don't, which could work differently (eg. having migration config in YAML rather than in PHP which seemed to be a huge thing for some whereas it absolutely means nothing to me. And: Which would be such an easy thing to implement into RockMigrations if need be...). I'll show why I think your statements are absolutely wrong in my opinion, but I'd be happy to hear your explanations first to get a better feeling of how RockMigrations is being seen by you or maybe also others, as I think that would be valuable feedback. Thank you ?

That's TailwindCSS, so that should not be the issue ? https://tailwindcss.com/docs/hover-focus-and-other-states

No doubt. But how do you manage all the e-commerce stuff that has to be done besides managing your products?