🇳🇴Norway @steinmb

Driveby review, but the proposed changes makes sense, it should be there.

steinmb → changed the visibility of the branch 850600-postgresql-driver-doesnt to hidden.

steinmb → made their first commit to this issue’s fork.

I am a little confused here. In ✨ PostgreSQL driver doesn't support SSL option Needs work is there indication that there is no SSL support but in this issue we have

+ * For requiring an SSL connection to a PostgreSQL database add:
+ * @code
+ * $databases['default']['default'] = array(
+ *   'init_commands' => array(
+ *     'sslmode' => 'require',
+ *   ),
+ * );

Going through older form API issues and found this. D9.x got https://www.drupal.org/commitlog/commit/2/08ff47b5fd1e9ff1039dba129ac1c4... →
What is left in here? Are we done?

Found note on order reading up on 🐛 HTML5 validation is preventing form submit and not fully accessible Needs work

1. Javascript validation first
2. HTML5 validation for no-Javascript
3. Server-side validation

Reviewing form API and found #2203649: Remaining Open Form API related Accessibility Issues → that took me here. This issue looks like it stalled, anything people can do to move it forward?

This simple oneliner have been sitting here for 2y, is there any active maintainers in here or? And, yes. RTBC.

steinmb → created an issue.

Seems to be coming from #2508759: set default 'Image Size' (useful for responsive Picture settings) → - Any other suggestions than the MR guards?

steinmb → created an issue.

Digging into a some performance issues on a site. Noticed this issue. Still needed or? The IS point to https://github.com/zendframework/zend-diactoros/blob/master/src/Response... that is archived and moved to https://github.com/laminas/laminas-diactoros/tree/3.4.x/src/Response that longer have this interface, could be renamed/moved though.

After 9y do I think we can unassign.

Thank you for the MR. Anyone know how to reproduce this error?

Assume this is a feature req. and as most of them, they are not critical. As the assigned person have not posted on about 7y, unassigned

Drive by review. RTBC

steinmb → created an issue.

From my understanding does this module not support wildcards. I might be wrong, let's hear it from the maintainer.

RTBC, should be a easy merge. Can we get this in? LGTM

Very interesting work. Xhprof lead me to this issue, as I am tracking down a performance issues in a D10.2.x —site.

select name, length(value) from key_value where collection='state' and length(value) > 10000;

 custom_fs_connector.basic_data          | 808712
 custom_fs_connector.info_type_name_list |  27342
 custom_room_info                            | 304317
 custom_fs_connector.course_code_list    | 101678

This is information that not often change, tough by reading through the issue and try to understand what is going on, I would say, this data should not be stored here but the site custom module. From my understanding is this data that not often change.

Thank you for testing, however, the failing tests with patch needs to be addressed to make this pass code quality. Manual tests alone is not enough.

As both D8 and 9 is EOL, this alone should be enough to tag a new official release.

Thank you for the detailed feedback, will try to follow your workflow. Note: CK4 we up to now we install by using composer, example: "ckeditor/ckeditor": "dev-full/4.21.x" giving maintainers more control of libraries floating around in libraries.

We just got an quotation from https://ckeditor.com/ on 4.x support on a yearly contract. It is expensive, I mean really expensive. We are considering spending the money on developer time getting CK5 supported here in stead.

Thank you for all your hard work!

LGTM

Move this here. Not sure if this still is an issue? PHP execution timeout can be tricky with `max_execution_time` and `max_input_time` by PHP and other limits introduced by userspace.

Even if this was created by Sun, I suggest we close this as "won't fix" or outdated.

Is this something worth spending time on keeping up2date? Not changed since 2017 - https://www.drupal.org/node/417166/revisions →

Old and solved.

This change was not committed to the 7.x-1.x branch and unfortunately was not part of the 1.0 release. @joseph - Got time to cherry-pick and tag a 1.1 version?

Given the current activity on D7 modules it might be difficult to legitimise the use of developer/maintenance time doing so. The issue is marked with "needs tests" though the patch introduce a single test with two assertions. Not sure if the tag was not removed or that this is too little tests. That might tip the scale. We could create a new branch and move this to, 7.x-2.x as an experimental feature. Not sure we win anything by doing so?

+ 1 I guess quite a few of us is going to have D7 around until at least jan 2025 and beyond as we are working through backlogs getting sites to D10/11. I am mostly worried for PHP comparability against newer versions of PHP as PHP 7.x is EOL and infrastructure is getting upgraded around us.

We always roll patches against dev. to make sure it safely can be applied and works with the latest changes.

https://github.com/phayes/geoPHP/issues/196

Consider this support req. answered.

There is a bug in the better_format module that prevented the editor from loading if only one format is available. If you use that module make sure your version of the module has that fix first.

Canceld https://frontendunited.com/coronavirus

Linking to the performance metrics support we are in the process adding to core. I think this would be very interesting trying to run this type of test though this.

Do we have any updated performance tests that also show number from our current 10.x?

Feature requests are "never" critical.

Thank you for your report.

What do you get if you run drush -vv cron

I stand corrected. Thank you for blowing through the issues and pushing a new version.

Looking at the activity for this module. Will we ever have a 7.x-1.x stable version? And why do we want that when 7.x.2.x already have first RC out?

No feedback, consider this fixed.

This seems to have been fixed in #2352847: Hide wysiwyg_status button from other account edit forms → in commit: 898d022c

Cannot find comment from the maintainer in #10 addressed in the latest patches, back to NW.

Old one [#358296] contains some documentation though I not sure how up to date it currently is and if still useful, perhaps it should be migrated to the new doc. system on ddo - https://www.drupal.org/drupalorg/docs/content/documentation#contrib →

The rest is going to be tackled in #2274177: Allow altering settings per editor and field → - Closing.

https://github.com/unverse/Whizzywing looks dead. Suggest we close this as an outdated/won't fix.

Re-reading the issue and linked Ctools issues. Looks to me that there is nothing left to do here.

Marking it as outdated.

I assume this still is the case in HEAD.

https://github.com/jejacks0n/mercury mostly dead since 2013. I suggest we close it as "won't fix" or outdated.

Suggest we close this as outdated.

Move to feature req. and they are normally never critical.

Quick update of this one liner. It it quiet the assumed false positive, lets get it in.

No feedback for a year and not be able to re-produce. Re-classing issue and marking it as fixed/answered.

In general, for modules with a 7.x branch that is without an active maintainer, I think it would help if there was a note on the modules front page about this, then sites owners can can make their own decisions:. Example:

- Roll their own PHP 8.x fixes.
- Remove the module from the code base, allowing them to continue running Drupal 7 on newer PHP versions until they have a Drupal 10.x installation up and running.

I have been reviewing a few old Drupal 7 installations lately, and most of them have modules that have not been updated the last 4-7 years. Perhaps https://getrector.com/ can be useful?

Thank your for getting back to me so swiftly.

I fully understand that the focus these days is other places then on Drupal 7 modules, the same goes for me, though, we are still stuck with quite a few Drupal 7 installations around. I think many people are happy with D7 modules "only" being updated to work with newer versions of PHP as now all PHP 7.x, and very soon 8.0, are EOL. Sometime we are forced to move PHP version due to, security policies, sometimes we have upgrade PHP as we replace servers and server OS. Not a bad thing as PHP 8.x is a pleasure to work with :)

@lesleyfernandes that is lovely news.

Seems to be answered

I see no blocker linked in here. Does that mean 1.7 is ready to be tagged and pushed?

I think we should postponed this on 🌱 Dealing with unexpected file deletion due to incorrect file usage Active

Mmmm, seems to me like a unrelated random fail. Let's try this one more time.

It would be nice if there was an active maintainer that could push a new release with this fix. #2 have been sitting there for about two years now.

Read though this issue, including #34, that mention there is a few separate issues that needs to be fixed. What are they, and where are they? I think the IS neeed to be updated to include what ever issues left. We might avoid noise in here, and it might give the pending issue more eyes.

Thanks. Not sure there is a an active D7 maintainer for this though.

Ref. #7, agree, it should.

Easy fix, RTBC.

Pushing it back to NW based on maintainer feedback in #7, though I am not 100% sure if this really needed?

Have a look at [2895968]

Think this is a support request and not a bug? Await feedback from @akshaykamble

8 months and still RTBC, any of the maintainers around to commit this?

An easy oneliner. See no reason to hold this back.

Looked at the patch in #5. The minim change in better_formats.module to make it show up (ref #12) was just to uncomment:

      if (count($options) === 1) {
//        $element['format']['format']['#type'] = 'hidden';

Non of our tester noticed this in staging and I just needed a hot fix.

I can re-produce this on both 7.x-1.x and 7.x-2.x.

1. Text field, an enable " Limit allowed text formats"
2. Select two formats
3. For users that have permission to both of these input formats, the editor work/load>/li>
4. For users that only have access to one of the input formats, the editor does not load. No error messages