bernhard

@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?

Thx @Robin S I definitely didn't have that on my radar! Do you have a suggestion what to use if I just want to make sure to get the images' field data as array independently from the template context but not showing temporary or unpublished items?

Totally agree. ProcessWire is so amazing I wish I could grow with it in larger scale projects. Totally disagree. At work we are 3 devs at the moment working on the same projects all the time and we have fully automated deployments both to staging and production. And it is easy to review and merge pull requests. And I've shared all that is necessary with the community. For free. And so has @LostKobrakai @MoritzLost Please stop stating your points in a manner that discredits the work of others or the way how others are working. Thank you. We have wire shell. Why don't you take up this project? You are obviously in need of such tools. Why do you keep bashing around and do not help improving the tools that we already have or help to make new tools being created and - also important - being shared with the community? I like that you bring up all those points, but I really don't like the way you are doing this. Imagine someone evaluating ProcessWire and somehow finding your thread or reading it by coincidence. Even if that person will likely not read it with the same emotions that I do he/she will still get an - in my opinion - wrong picture. I think it is in the interest of all of us to promote the things we have and to encourage everybody to take part.

And if you want to make things a little more obvious to anybody reading your code (or simply to yourself) you can use getUnformatted() to return the array version of the field no matter what the current outputformatting is: <?php $images = $page->getUnformatted('imagesfield'); if($images->count()) { $img = $images->first(); ... }

Sarcasm (scnr): I've noticed lately that the most valiant defenders of the opinion that PW lacks support for migrations are the ones that have never given https://processwire.com/modules/migrations/ (which dates back to 2016) and https://processwire.com/modules/rock-migrations/ (which has it's 3rd birthday next week ? ) a serious try ? ? Personal note: While I did not read your posting as offending as Ryan seams to have read it I can totally understand his reaction. I have not put a fraction of the time into ProcessWire compared to Ryan but still I was confused about some statements you made. And I know how it feels if you talk about things in a way you did in this thread and in a similar way you did in this thread and in this thread. It might not have been your intention, but it seems you are a bit quick in stating "how things are" and how they have to be... Back to topic (and I try to keep objective): -- Selectors -- Ryan has already answered here. I just want to add that I'm using array syntax for selectors a lot and I really like it ? BTW: Just noticed that it's also a birthday for selector array syntax: https://processwire.com/blog/posts/processwire-3.0.13-selector-upgrades-and-new-form-builder-version/#selector-engine-array-support Happy Birthday and thanks for being with us and being a reliable tool in my everyday work for the last 6 years ? Could you please explain the vulnerability here for others to learn from your example? -- Features -- I just wanted to share that I've had quite the opposite experience with a lot of tools that I've tried over the last view years. At first sight there was a lot of bling bling and shiny cool things, but at second sight I found limitations here and other annoying parts there. Maybe I've just tried the wrong tools but with ProcessWire my experience was exactly the opposite: My first impression was that it is by far too simple for what I need. Several years later I feel like I'm just scratching the surface ? -- Twig -- I'm SO happy that we don't have such a layer by default in ProcessWire!! I've not worked much with template engines but I've used smarty back in 2004 so it's not that I don't know that such tools exist or what they are for. Though what I do a lot is keeping my template files as clean as possible. How I do that? I use custom page classes everywhere and if I need just a little bit of logic somewhere I put that logic into the page class to keep things simple on the frontend part. What I really like here is one of the biggest benefits of PW of all: It keeps simple things simple and makes complex things possible (and fun). If you have just started (with PW or with web development in general) you can simply echo some page properties and see the result on the screen. No additional tools. No necessary build chain. No template engine. Just PHP and HTML. Great ? In my opinion ? I've recently had to try another open source CMS. That CMS has native support for migrations as everything goes into YAML files. It has fancy backend editing for everything. Fancy, yes. But that adds another layer of complexity to the whole thing as well. Imagine how long it took me to understand how I can create a single field and display the content of that field on the frontend? Long. Very long. I don't want to tell you how long. ? Because of all that fancyness that system uses a custom language for rendering all the fields. It was a terrible experience for me and I felt really bad that I as a quite experienced PHP developer was not able to achieve simple things in a PHP based content management system. One user commented on one of their youtube tutorials that it's another perfect example of a german product developed by a few geniuses but impossible to use for the average dev. I agree with him and I'm happy that ProcessWire takes another route! -- Documentation -- I agree that lots of information is scattered around somewhere (in the forum, in the docs or in code), BUT (and that's the part you didn't mention and which is just another example of why things might be taken personally): In my opinion ProcessWire (or Ryan) does a lot right in that regard and is way ahead compared to other tools I've used (maybe tried the wrong tools again). For example the docs in code are absolutely great! Nearly every method that I need to inspect has some explanation directly in code so I can quickly jump to that place in my IDE or even get helpful pieces of the docs instantly as tooltip: Next, the forum: WHAT A GREAT PLACE!! I've been on another system before I discovered PW. They had a forum as well... But I simply did not get help there. I posted a question and did not know if I'll get an answer in one week or two, if ever. That was such a pain and PW is so great in that regard! It might be a small community but the support is outstanding. I've also seen other products that have a discord channel or something similar. Maybe forums are old-school, but in my opinion they are still great and will be for a long time. You have an archive where everybody can find answers to their questions and learn from posted answers. And one other great thing is that 90% of those answers will likely still just work if you apply them today even if they are several years old. -- Version numbers -- What I'd pick up from that point is that some of the strengths of PW might look like weaknesses for others on first sight. Just as the simple and clean backend for me looked like PW is not capable of complex things the used version numbers and the fact that the github master branch might not see any updates for several months can give the impression to others that the project is not actively developed. It's a matter of everybody's perceptions and expectations. ProcessWire could to more in that regard. But on the other hand I really appreciate that it (or Ryan) does not care as much about that as other systems do. The downside of this is that it can be hard to sell to other devs and/or clients... -- A word to Ryan -- I don't agree with you here and I think that's a blind spot on your end. ? When I started developing my first custom Fieldtype it took me quite long to understand how things work. Learning from the events fieldtype was really hard! It is obvious and simple once you know how all the pieces play together (you basically just need an inputfield and a related fieldtype for sleep() and wakeup(), right?) but it was really not easy to start with a blank screen in my IDE without having this concept in my head and then put all those pieces together one by one trying to understand what they do and then making them do what I want. I guess we didn't even have TracyDebugger back then. ? (By the way - how great is Tracy?! Another invaluable tool in our Ecosystem that I don't want to miss!) I think it's similar to what happened when I first discovered the PW backend. This was one of the most liked posts in the forum so I think it was and maybe still is not obvious to many how easy it actually is to work with and customize the PW backend. As a side note I think that might be one reason why PW is still underestimated in regards to being not only a wonderful tool to create websites but also a wonderful tool to create web applications. And I have to do it again: I think RockMigrations is just another example of something in PW that looks more complex than it actually is. And an example of something that looks less powerful than it actually is. I've taken that learning from the other threads and already improved the module greatly. The next version will make it a lot easier to get started with. Maybe that will open some eyes. And maybe Ryan will also revisit this thread one day and will recap and pick up some of the things that were mentioned. There were some good points in it and the amount of reactions shows that, I think. So thanks for bringing those topics up @MoritzLost and thanks for the insights as always @ryan.