netcarver

Personally, I think a table would really help the clarity of the server details. | Server | Version | | ------:|:------- | | PW | $pw_version | | PHP | $php_version | | ... Edited to add: At least to my eye, it's hard to tell that the "Server Details", "Server Settings" and "Module Details" lines are actually click targets that open up a hidden list. Yeah, I know there are triangle markers as visual clues, but I mistook those simply as list-item markers the first couple of times I saw these in issues. I'm more used to click targets being styled as links or saying something like (more...) or something like that.

@adrian Fantastic! Thank-you, that works great. Regarding the "Lite" reporting button idea; I'd gather a few more opinions on this before doing anything. For example, another alternative is to just keep the existing button but make the basics a non-collapsed table with all the additional details in the collapsed sections following it. That would make the basics stand out pretty well in the issue reports.

@adrian Thanks, that's fixed it, and nothing lost. While you have this feature in your working memory, another request: could you have the config scroll to the custom PHP field if it were changed on the last save? That would allow a smoother flow of iterations using the field, and shouldn't interfere with anyone else's use of the config area. That would be the icing on the cake, but I'm totally happy with the cake the way it is at the moment ? --- With regard to the Version List functionality, if anything, I think a "lite" version for initial reporting of just the PW, PHP, Webserver & MySQL versions as a markdown table would be useful. One thing that's struck me reading through the issues is that clarity matters. I really like the comprehensive data you've made available with the existing feature - but I completely missed the data, tucked away at the bottom of a couple of issues. It was only when I found the feature in Tracy that I had a lightbulb moment and realised that's where those three lines in the issue reports came from. (I like to follow the KISBIS rule where possible: Keep It Simple, Because I'm Stupid)

@adrian Thanks for the update - just tried it - but the value of the field no longer seems to save. Whatever I enter into the custom PHP code editor is lost on submit of the module settings.

@adrian Thank you. I was putting together a version-gathering script to collect the data to paste, as Markdown, into GitHub issues - then guess what I found elsewhere in TD ?

Hi @prestoav have you considered opening this as an issue, either of consistency in the processwire-issues repository, or a feature request on the processwire-requests repository?

@teppo and @LostKobrakai Thanks for the pointers, that helps clarify things for me. I was under the mistaken impression that anyone adding a comment to a closed issue re-opened it. @gmclelland Ouch - let's hope we never reach those dizzy heights. @matjazp Thank you. Many thanks to everyone who responded to my promptings via github or PM here on the forum - really happy to see there have been 51 fixed or duplicate issues closed in the last week. We're still awaiting resolution on about another 15 that I've posted on, but I hope some of those will be closed this week. I've been working through some older issues, trying to reproduce them - and I think that we can all help Ryan by trying to do describe the reproduction pathway as clearly as possible (there are issues that are somewhat ambiguous,) and considering if a little screen capture might help. Also, Tracy has a feature that allows versions, modules and the like all to be dumped in a Markdown-friendly format that can be pasted right into issue reports. Once the "Copy for Github" button has been pressed, you can simply paste it in at the end of your issue report. Very helpful - and I only found out about it yesterday ?.

Hi @adrian A feature request for your consideration: please could you apply the lovely code editor to the custom PHP textarea in the module settings? Would make editing custom PHP much easier. Many thanks for your consideration! Steve

@LostKobrakai I'm probably misunderstanding this then, but here's what I see on issue 514... Looks like it was re-opened by the initial opener, but my comment on the issue didn't do it.

I remembered incorrectly! ? The person who initially opened the issue can continue re-open the conversation after closure - but not a 3rd party. So the conversation can't just be picked up re-opened by anyone.

@gizomo Here are a few other options for your consideration, in case this is not ready for sharing. In no particular order (and I haven't used any yet - so no recommendations)... https://github.com/nicoknoll/ProcessNewsletter https://github.com/pmarki/ProcessSendNewsletter https://github.com/rolandtoth/pwnl https://github.com/justb3a/processwire-newslettersubscription https://github.com/dauni/processwire-newslettermanagement Hope that helps. </redirect>

Hi @ak1001 , are you 100% sure the MySQL server address, port, username, password and DB name are correct?

Hi @sebastiaan and welcome to the forum. You could try this... $role_list = wire('pages')->find('template=role'); I also highly recommend installing the Selector Test module or the Tracy Debugger Module so you can explore using PW's selectors for this sort of thing.

@Robin S @Sten Actually, this looks really useful. Do you think that you could, between you, publish this module to module directory?

Well, nice to see some fixed issues being closed now. I count 35+ closures since yesterday, which takes the project well below 200 open issues. I do hope that some progress can be made on other items. Can we ease creating pull requests for small items in any way, perhaps that would help the overall effort?

It seems I didn't sample enough of the comments put on the issues. Not all of them @ mention the initiator - so my comment isn't totally valid. I've therefore started @ mentioning the initiating party on the resolved threads - but it takes a while, so I'm appreciating @gmclelland's robot suggestion more now, though I think I'd not want it to auto-close issues but rather auto-remind the initiator to do the close, and later flag it for a human closure decision.

PHP7.1 still has mcrypt.

@Macrura mcrypt is no longer part of PHP as of version 7.2. You can still install it via Pear. Do you have a file + line number for the deprecated warning? Update: There is a possible polyfill here - I've not used it myself.

@wbmnfktr No problem ? @adrian I agree with you (and, as it happens, I agree with your analysis in that issue - it was one of the ones I read before starting this thread), and dealing with these semi-subjective issues is more difficult than the clear-cut cases of a bugfix. However, I'd like to still advance the thought that having a closed issue re-opened, perhaps multiple times, would send a louder signal than keeping it open indefinitely and just having someone give the occasional thumbs-up to one of the pro-posts.

Thanks for the feedback everyone; some really good ideas here. I guess that Ryan and Francesco are the ones who get to declare if things are getting out of hand though ? Whilst there is, obviously, the ideal issue closure (issue closed by the opening poster after verification that it is really fixed); the reality is that many of the issues have been left unanswered for many months following a commit to the codebase, addition of a tag and a comment on the issue with an @ mention to the person who raised it. If there is no feedback for months following these actions, I'd personally be inclined to close the issue with an invitation for anyone to re-open with a follow-up post if needed. IIRC anyone can re-open an issue by simply posting a new entry on it; closure does not necessarily mean an end to a conversation. Best wishes! Steve

Hello @ryan and @Francesco Schwarz, There are currently a lot of issues (about 20% of the total) that are still open on the processwire-issues repository but marked as "Resolution: fixed (close when ready)." Some of these date back over a year. I doubt many of the older ones will ever be closed by the initiator. There is a similar situation building up with the issues tagged as "Resolution: Not a bug" - though there are less of them. If that's the case, how about closing any issues that are 3+ months old (or that have not been tagged as a discussion) with a polite note that the issue should be re-opened if needed? This would really help reduce the list of open issues.

@Robin S thank you, that works fine.

I use the method @psy is talking about and it works well.

Thanks for the update and warning note, @Macrura. I'll test this later on a development box. Update: Seems to work for me now, thank you!

@adrian I guess it will vary. I can't see people with smallish brochure sites wanting it. However, I'm currently using PW to build an admin system for a charity. Most of the users are probably using their (child|spouse|pet)'s name + a year of birth as their password, yet they are trusted to handle their own client's confidential information on the system. I see 2FA as a big win for this kind of user, as a small change in log-in protocol can bring in a big benefit for the charity and its clients, by mitigating the risk of such poor passwords.