d6lts / drupal Goto Github PK

The current version is 6.55. As mentioned in #34, it's an easy way to check if a site'd Drupal install has been updated.

Hi there,
Awesome work on LTS release so far! I'm trying to get an old D6 site to run well on PHP 7.2, and so far, it seems to work.

PHP 7.2 throws a warning if we try to call count() with a parameter that is not an array or implements \Countable interface. This raises several warnings in many projects. I will try to send PRs as I work on them.

Additionally, the function each() is deprecated and there are some occasions that this function is used. I will work on PRs for them as well.

May I suggest that we tag this issue in PHP 7.2 compatibility fixes so they are easy to track?

Thank you.

Problem with utf8 chars in quoting function in includes/common.inc in function "function drupal_to_js($var)"

Problem occurs in Views Admin in the "Filter"-Widget with a many-to-one relation:
project/admin/build/views/nojs/config-item/startseite_phase1/page/filter/field_from_ba_value_many_to_one

The function returns a json-string in

{ "display": "\x3cform action=\"\"\x3e ... \x3c/form\x3e\n", "title": "Page: Filter \x3cem\x3eInhalt: Bezirksamtseingabe (field_from_ba) - Zulässige Werte\x3c/em\x3e konfigurieren", "url": "https://www.berlin.de/ba-spandau/buergerhaushalt/admin/build/views/ajax/config-item/startseite_phase1/page/filter/field_from_ba_value_many_to_one", "js": { "viewsAjax": { "formRelationships": { "edit-options-value": { "num": 1, "values": { "radio:options[operator]": ["or", "and", "not"] } } } } }, "hilite": ".views-item-page-filter-field-from-ba-value-many-to-one" }

It should be
"display": "\u003Cform action=\"\"\u003E ... \u003C/form\u003E\n",

Fix found in Module jquery_update/patches/drupal_to_js_proper_json-D6.patch

The last part of the regex |\.bak|\.orig\.save)$"> does not look right, it seems that the | is missing before \.save, I think it should be |\.bak|\.orig|\.save)$">, at in least D9 looks like that. Imho it should match files php.orig and php.save … not php.orig.save

dd34383#r66853188

Hello,

This commit:
078a90b
introduced a critical bug affecting sites where $db_prefix (set in settings.php) is an array.

For example:

    $db_prefix = array(
      'default'   => 'default_',
      'users'     => 'www_',
      'sessions'  => 'www_',
      'mytable'  => 'custom_',
    );     

In function db_prefix_tables($sql) (includes/database.inc):

    if (array_key_exists('default', $db_prefix)) {
      $tmp = $db_prefix;
      unset($tmp['default']);

      foreach ($tmp as $key => $val) {
        $sql = strtr($sql, array('{' . $key . '}' => '{' . $val . $key . '}'));
      }
      $sql = strtr($sql, array('{' => '{' . $db_prefix['default']));
    }

The above code will turn {mytable} to default_custom_mytable instead of the expected custom_mytable.

The critical line is this one:

$sql = strtr($sql, array('{' . $key . '}' => '{' . $val . $key . '}'));

which introduces back curly brackets, which triggers the next strstr() command to add the default prefix on top!

The fix is to revert that line to what it was before:

$sql = strtr($sql, array('{' . $key . '}' => $val . $key ));

I don't know what motivated changing that particular line, but looking at the whole commit, it does not seem necessary to change this line to achieve the intended overall purpose, which was to add backquotes for MySQL 8 compatibility purposes.

There are two calls to

$log_sanitized_keys = variable_get('sanitize_input_logging', FALSE);

First on line 1679 and then on line 1684. I may be missing something, but to me it looks like only one is needed.

Hi,
If this release of drupal 6 suppose to support php 7,
How there are php functions that doesn't exits in php 7?
Like ereg_replace and others?

Just did the upgrade to 6.46 and am getting the following php error

Creating default object from empty value in  modules/profile/profile.module on line 493.

This is occurring on nodes where user profile information is displayed - see https://www.f1m.com/content/kits/brabham-bt48-dutch-gp

The site is still running PHP 5.6.38

Eric

This is a very low priority bug, because most people aren't installing new Drupal 6 sites, but it's really annoying during testing!

On the step of install.php where it asks for the database credentials, you always have to enter the database credentials twice. The first time you submit the form, it just comes back blank with no messages. On the second submit, it works per normal.

I suspect that this issue has to do with the default value for some variable being the wrong type, because the automatic type conversion in PHP 7 is much stricter than PHP 5. I've noticed other situations where Drupal 6 code would set a variables default value to empty string and then use it as an array, and other such oddities that get automatically corrected in PHP 5, but fail to work in PHP 7. But that's just a random guess.

6.58 update doesn't work on my system. shows all previous drupal core updates needed attached.

Is there any hope/plan for supporting php 8.*?

session_destroy(): Session callback expects true/false return value in /var/www/releases/modules/user/user.pages.inc on line 151.

Hi @dsnopek,

Its great to know that there is a plan to support PHP 7 on Drupal 6 LTS. Shall I know when we can expect the release?

The website listed at https://github.com/d6lts ; https://www[.]mydropwizard[.]com/drupal-6-lts is now a spam domain :/

An XSS vulnerability has been found in Drupal Core that is related to the jQuery UI contrib module:

• CVE-2021-41183: XSS in the of option of the .position() util [4]

For more details:

https://www.drupal.org/sa-core-2022-001

The suggested solution:

Install the latest version:

• If you are using Drupal 9.3, update to Drupal 9.3.3 [6].
• If you are using Drupal 9.2, update to Drupal 9.2.11 [7].
• If you are using Drupal 7, update to Drupal 7.86 [8].

All versions of Drupal 8 and 9 prior to 9.2.x are end-of-life and do not receive security coverage. Note that Drupal 8 has reached its end of life [9].

Is there a Drupal 6.60 release that fixes the these XSS vulnerabilities?

I'm running Drush version 8.1.18 on a site with the latest 6.49 that was upgraded to fix the phar:// vulnerability fixed in https://www.drupal.org/sa-core-2019-002, and had the 7.63 hotfix applied. However, I'm getting a "Drush command terminated abnormally due to an unrecoverable error" message whenever I try to run drush

I don't see any debugging info in the PHP error log.

When i do drush -d, it looks like it is failing during bootstrap_drupal_full().

Could this be related to or https://www.drupal.org/project/drupal/issues/3026560?

However, my Drush appears to work on 7.63, even though 6.49 appears to have the same hotfix code.

I have the drush phar executable at /usr/local/bin/drush, which is a symlink to /usr/local/bin/drush.phar. I've tested running "drush.phar" also.

Both 6.48 and 6.49 versions have an old CHANGELOG.txt file from version 6.47

Hi,

One last theme.inc change that reduced errors on my site.
theme_inc.zip

I found the issue #15 and assumed that drush8 support should actually be already there.

I installed drush via composer using

composer global require drush/drush:8.*

and also used the phar variant described in

https://docs.drush.org/en/8.x/install/

using

wget https://github.com/drush-ops/drush/releases/download/8.4.8/drush.phar

The result for cc all is the same

./drush.phar @localize cc all
No Drupal site found, only 'drush' cache was cleared. 

~/.config/composer/vendor/bin/drush @localize cc all
No Drupal site found, only 'drush' cache was cleared.

Interestingly, things like sqlc and uli do work, esp. the latter means, the context could be loaded and drush is aware of the installation.

Drush status looks like this

Drupal version         :  6.59                                                                                           
 Site URI               :  localize.lan                                                                                   
 Database driver        :  pgsql                                                                                          
 Database hostname      :  db                                                                                             
 Database port          :                                                                                                 
 Database username      :  dw_localize                                                                                    
 Database name          :  dw_localize                                                                                    
 PHP executable         :  /usr/bin/php                                                                                   
 PHP configuration      :  /etc/php/7.4/cli/php.ini                                                                       
 PHP OS                 :  Linux                                                                                          
 Drush script           :  /home/www-data/.config/composer/vendor/drush/drush/drush.php                                   
 Drush version          :  8.4.8                                                                                          
 Drush temp directory   :  /tmp                                                                                           
 Drush configuration    :  /home/www-data/.drush/drushrc.php                                                              
 Drush alias files      :  /home/www-data/.drush/all.aliases.drushrc.php /home/www-data/.drush/localize.alias.drushrc.php 
 Drupal root            :  /var/www                                                                                       
 Drupal Settings File   :  sites/default/settings.php                                                                     
 Site path              :  sites/default      

The drush alias looks like this

cat ~/.drush/localize.alias.drushrc.php 
<?php

$aliases['localize'] = array(
  'root' => '/var/www',
  'uri' => 'localize.lan',
  'strict'=> 0,
);

cat ~/.drush/all.aliases.drushrc.php 
<?php

$aliases['all'] = array(
  'root' => '/var/www',
  'site-list' => array(
    '@localize'
  ),
);

Also as bottom line, drush6 does work without issues.

Any hints what might be the cause?

Hello

I upgraded a site to the latest d6lts version 6.47, when I switch my php version in lando to 7 or 7.1 I get this:

Call to undefined function mysql_real_escape_string() 

I know all mysql_ functions have been removed in php 7+, so how are you handling this issue on your d6 sites that run php7?

For the .htaccess that's added to the user uploaded files directory to provide the same security fix for PHP 7, it needs some updates. We need some way to make sure that when people update to the next release of Drupal 6, that this file gets updated.

Hi, I have an issue which I cannot solve:
I have modified my drupal 6 installation to make it compatible to php7.2 and the site is actually working ok and is up and running.
The only problem I found is that drush 8 cannot recognise the site and actually cannot connect to it's database. Did you have a similar problem?
I have posted this question also here (drush-ops/drush#3700) but as people don't consider drupal 6 working with php 7+ I don't expect to find any answer there...
Any hint would be useful...

Since 6.28, I've been applying this patch to /var/www/includes/common.inc to quiet down errors in my logs for certain PHP warnings. Maybe could be added?

mktime(): You should be using the time() function instead in /var/www/includes/common.inc(1773) : eval()'d code on line 6.

here's the old patch:

diff --git a/includes/common.inc b/includes/common.inc
index 2abf198..d59a611 100644
--- a/includes/common.inc
+++ b/includes/common.inc
@@ -665,7 +665,11 @@ function drupal_error_handler($errno, $message, $filename, $line, $context) {
     return;
   }
 
-  if ($errno & (E_ALL ^ E_DEPRECATED ^ E_NOTICE)) {
+  $error_const = E_ALL ^ E_DEPRECATED ^ E_NOTICE ^ E_STRICT;
+  if (version_compare(phpversion(), '5.4.0') < 0) {
+    $error_const = E_ALL ^ E_DEPRECATED ^ E_NOTICE;
+  }
+  if ($errno & $error_const) {
     $types = array(1 => 'error', 2 => 'warning', 4 => 'parse error', 8 => 'notice', 16 => 'core error', 32 => 'core warning', 64 => 'compile error', 128 => 'compile warning', 256 => 'user error', 512 => 'user warning', 1024 => 'user notice', 2048 => 'strict warning', 4096 => 'recoverable fatal error');
 
     // For database errors, we want the line number/file name of the place that

I know it's not possible to add multi-byte support to Drupal 6, but I have a situation where users sometimes include emoji when posting to our Drupal 6 issue tracker website, which causes node or comment creation to fail. I'd like to build in some protections against this.

I'm opening this issue in hopes of sanity checking my workaround, and looking for feedback if this is a stupid idea.

I'm thinking that i might just be able to hack db_escape_string() to add this line:

$text = iconv("utf-8", "utf-8//ignore", $text);

Is there any reason this would be a particularly horrible idea, and/or am I putting this hack in the wrong place?

Path: /admin/build/block

Here's the warnings:

warning: Illegal string offset 'region' in /app/modules/block/block.admin.inc on line 101.
warning: Illegal string offset 'status' in /app/modules/block/block.admin.inc on line 101.
warning: Illegal string offset 'status' in /app/modules/block/block.admin.inc on line 102.
warning: Illegal string offset 'region' in /app/modules/block/block.admin.inc on line 102.
warning: Illegal string offset 'region' in /app/modules/block/block.admin.inc on line 102.
warning: Illegal string offset 'status' in /app/modules/block/block.admin.inc on line 103.
warning: Illegal string offset 'weight' in /app/modules/block/block.admin.inc on line 103.
warning: Illegal string offset 'region' in /app/modules/block/block.admin.inc on line 103.
warning: Illegal string offset 'module' in /app/modules/block/block.admin.inc on line 103.
warning: Illegal string offset 'delta' in /app/modules/block/block.admin.inc on line 103.
warning: Illegal string offset 'theme' in /app/modules/block/block.admin.inc on line 103.

Is there a Drupal 6.60 release that fixes the following XSS vulnerabilities?

An XSS vulnerability has been found in Drupal Core that is related to the jQuery UI contrib module:

• CVE-2021-41182: XSS in the altField option of the Datepicker widget [5]
• CVE-2021-41183: XSS in *Text options of the Datepicker widget [6]

Furthermore, other vulnerabilities listed below were previously unaddressed in the version of jQuery UI included in Drupal 7 or in the jQuery Update [7]
module:

• CVE-2016-7103: XSS in closeText option of Dialog [8]
• CVE-2010-5312: XSS in the title option of Dialog [9] (applicable only to
  the jQuery UI version included in D7 core)

Important note regarding the jQuery Update contrib module

These backport fixes in D7 have also been tested with the version of jQuery UI provided by the most recent releases of the jQuery Update module (jQuery UI 1.10.2) and the fixes confirmed. Therefore, there is no accompanying security release for jQuery Update.

However, in early 2022 the currently supported release of jQuery Update
(7.x-2.7 from 2015) will be deprecated and replaced by a new release from the 7.x-4.x branch. The stable release from that branch will then be the only release considered by Drupal Security Team when new jQuery security issues arise.

Please check the jQuery Update project page [11] for more details, and for announcements when the changes are made to supported releases.

For more details:

https://www.drupal.org/sa-core-2022-002

The suggested solution:

Install the latest version:

• If you are using Drupal 7, update to Drupal 7.86 [12]

Why was the release date for 6.42 created in 436f4aa rolled back with 3ef9dcf? This makes it appear that 6.42 was released on 2018-Feb-22, prior to the 3/28 release of the SA-CORE-2018-002 patch.

drupal-6.42-release-date.pdf

Don't know if it is intentional, but I guess supporting MySQL 5.7 has the same "ONLY_FULL_GROUP_BY" problem that prevents D6LTS working on MySQL 8.0.
I upgraded a working D6LTS v6.59 to MySQL 5.7 (my hosting company is not supporting MySQL 8) and taxonomies' querys got broken. However, adapting the modified code in database.mysqli.inc to disable ONLY_FULL_GROUP_BY also for 5.7 made the site working fine again.
Maybe you could easily add support for 5.7.

BTW: a big thank you to My Drop Wizzard team for your work on D6LTS. I just have a humble site and can't hire any of your plans, but you have been reallly helpful. I owe you some beers!

Ik got this message:
Only variables should be passed by reference in /public_html/modules/book/book.module on line 559.

I changed back to the book.module of version 6.44. Two lines where changed into one line, which appears to be not correct.

After upgrading to 6.51 I got this warning many many times while running update.php:

warning: substr() expects parameter 1 to be string, array given in /home/photontst/domains/test.photonmagazine.nl/public_html/includes/database.inc on line 358.

my PHP: 7.1.25
my MySQL: 5.6.38

Perhaps we should update changelog for this version 6.43?

Are there plans to port the PHP 7.2 fixes to the Pressflow fork?

Just wondering if you have a special script or something? Can it be shared?

Thanks!

There were some bugs identified in https://www.drupal.org/project/drupal/issues/352359 that might be worth committing.

Notice: Uninitialized string offset: 10 in drupal_substr() (line 552 of includes/unicode.inc).

I updated misc/drupal.js, includes/common.inc and includes/bootstrap.inc on a 6.38 Drupal install, and now I'm getting a 500 error when I attempt to log out or edit a page and click "submit".

The submit goes through, just FYI.

There appear to be no errors in watchdog or error_log.

Did I miss a file that was updated or is something a little wonky with the security update?

UPDATE: I was able to get it to show an error message: "Fatal error: Call to undefined function drupal_save_session() in /httpdocs/includes/session.inc on line 210"

I see that mysql 8.0 is supported and I guess from the older days, pg 9.6 will be supported to (I tried 9.6, it worked).

I also tried pg 12 and yet it seems to work too. My site is fairly limited, it is only used for translations, so views/bulk and potx, some l10n stuff and that's about it. No CCK even.

What are your expectations with d6lts and pg 12?
Also, maybe a different topic, if i find any issue and patch those, would you be interested in merging those?

I understand, nobody can judge anything about the contribs, so the question can be handled differently for
a) core
b) contribs (which are already part of d6lts like views/views bulk)
c) yet unsupported contribs

Background: we picked 12 because of the changesin cluster setups and performance of pg12. We cannot really downgrade since tools like crunchydata only support pg12+ nowadays. (most of them).

Let me know about your thoughts!

I solved the issue of the attached uploaded files not showing by editing the upload.module: Line 278 - 284
case 'load': $output = ''; if (variable_get("upload_$node->type", 1) == 1) { $output['files'] = upload_load($node); return $output; } break;
Changed to
case 'load': $output = array(); if (variable_get("upload_$node->type", 1) == 1) { $output['files'] = upload_load($node); return $output; } break;

Typo. $execlude, needs to be $exclude.

A recent update to Apache (2.4.52) will cause URLs with spaces and other special characters to fail. For example:
Go to https://example.com/search
Search for "this and that"
This will take you to: https://example.com/search/node/this and that
and a 403 Forbidden message

Adding a "B" flag to rewrite rules in the .htaccess file in the top directory of Drupal 6 fixes this:
From:
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
To:
RewriteRule ^(.*)$ index.php?q=$1 [B,L,QSA]

See: https://stackoverflow.com/questions/75684314/ah10411-error-managing-spaces-and-20-in-apache-mod-rewrite

I downloeaded files here on this git and uploaded it to my server.....
then I deleted my old setting file and used default.setting.php from this git and rename it to settings.php and updated my db info
in line 92

my site is broken now