Could you please apply tags for the latest d6lts releases? Versions 6.45 and 6.46 exist on the master branch, but have not been tagged.

I upgraded to 6.23 and am in the middle of simpletest development. I am unable to get debug function to work. Plus, the yellow exceptions that used to show up in my test are no longer showing up. I'm am going to test debug() on a fresh install of pressflow.

http://drupal.org/SA-CORE-2013-001

Thanks!

I receive this error
notice: Undefined property: stdClass::$teaser in my_path/sites/all/modules/nodewords/nodewords_tokens/nodewords_tokens.module on line 257.
how can i fix it?

If I use:

drupal_get_form('my_form', $param1, $param2) the form is not rendered correctly.

Only works if I use:

drupal_get_form('my_form') with no extra parameters.

I'm working with PressFlow 6.27.

Hi guys. If my git foo was sharper and I was more familiar with Pressflow I'm sure I could figure this out but coming in off the street I it's not clear which tag I'm supposed to use in production. pressflow-6.25.108, DRUPAL-6-22, 6.25?

Thanks!

Another security update for Drupal 6 core:

https://drupal.org/SA-CORE-2014-001

Thanks!

Hello,

It looks like you have merged in the Drupal core 6.23 security update, but have not tagged a new release. This is causing the Update Status module to report that core is still out of date. Any plans to tag the new release?

Also, it looks like you are still using the old CVS naming conventions for tags. Any plans to start using the new naming conventions (i.e. "6.23" instead of "DRUPAL-6-23")? It would make things less confusing for those of us using git_deploy for update reporting.

Thanks!

A single insert is faster/means less trips. It's MySQL/later versions of postgres only so can't do it for d6 regular.

Are there plans to have this patch ready for Pressflow 6? @dsnopek https://www.mydropwizard.com/blog/drupal-6-highly-critical-security-release-march-28th-psa-2018-001

Any reason nobody has pulled this change in, we run into this almost every day with json services, that proper chr encoding and decoding causes issues esp when dealing with mobile devices that need proper unicode/utf8 encoded chr data..

http://drupal.org/node/1086098
#84 seems to cover all bases

Problem / motivation

David Snopek (@dsnopek):

• maintains the Drupal 6 Long Term Support project on Drupal.org,
• is working on porting upcoming SA related to PSA-2018-001 to Drupal 6, and,
• has contributed to a number of improvements to this repository already (#114, #112, #104, #101 (see comments)).

I no longer maintain any Drupal 6 sites, or work with it at all (and to some extent, started as a maintainer to pressflow/7).

It sounds to me like @dsnopek would make an excellent maintainer for pressflow/6!

Proposed resolution

Add @dsnopek to the pressflow organization on Github.

Please see https://drupal.org/node/1918820

Recommendation: use gm_date('D, d M Y H:i:s').' GMT'

We had to patch it for proper proxying.

Drupal 6.26 has just been released: http://drupal.org/node/1558054

Thank you.

As of pressflow-6-72361f3 master of 13/12/2012, SimpleTest tests fail when using Posgresql database (8.4) because of a difference between Mysql and Postgres in the way they handle the data type Serial. The following patch to system.install resolves the issue and fixes all the tests.

diff -r -u /tmp/pressflow-6-72361f3/modules/system/system.install ./modules/system/system.install
--- /tmp/pressflow-6-72361f3/modules/system/system.install      2012-05-02 23:59:43.000000000 +0000
+++ ./modules/system/system.install     2012-12-13 05:13:33.000000000 +0000
@@ -379,13 +379,13 @@
   // uid 2 which is not what we want. So we insert the first user here, the
   // anonymous user. uid is 1 here for now, but very soon it will be changed
   // to 0.
-  db_query("INSERT INTO {users} (uid, name, mail) VALUES(%d, '%s', '%s')", 1, '', '');
+  db_query("INSERT INTO {users} (name, mail) VALUES('%s', '%s')", '', '');
 
   // We need some placeholders here as name and mail are uniques and data is
   // presumed to be a serialized array. Install will change uid 1 immediately
   // anyways. So we insert the superuser here, the uid is 2 here for now, but
   // very soon it will be changed to 1.
-  db_query("INSERT INTO {users} (uid, name, mail, created, data) VALUES(%d, '%s', '%s', %d, '%s')", 2, 'placeholder-for-uid-1', 'placeholder-for-uid-1', time(), serialize(array()));
+  db_query("INSERT INTO {users} (name, mail, created, data) VALUES('%s', '%s', %d, '%s')",'placeholder-for-uid-1', 'placeholder-for-uid-1', time(), serialize(array()));
 
   // This sets the above two users uid 0 (anonymous). We avoid an explicit 0
   // otherwise MySQL might insert the next auto_increment value.

I spent a lot of time debugging this until I found the issue, which I am not sure what it is but at least I found a way to reproduce it on a bare install of pressflow rather than on my drupal site which I am migrating to pressflow.

If you empty the sessions table and run update.php as anonymous (previously allowing this on the settings.php file), once the batch process start you get a WSOD.

I have isolated the reason, however, I am not sure if this is an actual consequence of the pressflow addition to drupal core or if this is actually a bug. Also this is mitigated by the fact that if you do this as the admin user everything seems to work properly, however, it worth mentioning.

The problem appears in

<?php
/**
 * Commit the current session, if necessary.
 *
 * If an anonymous user already has an empty session, destroy it.
 */
function drupal_session_commit() {
  global $user;

  if (empty($user->uid) && empty($_SESSION)) {
    if (drupal_session_started() && drupal_save_session()) {
      // Destroy empty anonymous sessions.
      drupal_session_destroy();
    }
  }
  else if (drupal_save_session()) {
    if (!drupal_session_started()) {
      drupal_session_start();
    }
    // Write the session data.
    session_write_close();
  }
}

specifically in the following snippet:

<?php
  if (empty($user->uid) && empty($_SESSION)) {
    if (drupal_session_started() && drupal_save_session()) {
      // Destroy empty anonymous sessions.
      drupal_session_destroy();
    }
  }

As this function is triggered on a normal drupal_goto() and in the case of an anonymous user and an empty session, the session will be eventually destroyed, so when the update.php is reached again by the batch API, a new session will be generated which leads to a new session ID and then, the batch process is never found because it uses a batch ID and a token which is built from the new session ID and then never found on the db.

If I am explained or pointed in the direction of fixing this I don't mind submitting a patch, otherwise it might be good to either document this or prevent update.php from be run as anonymous.

Looking at the version tags via bit, it appears that pre-6.22, the tags switch to drupal rather than Pressflow. I would like to be able to utilize earlier versions of pressflow, but cannot check them out. Are they available somewhere? Tags within the github repo would be ideal, but even a tar would help.

Thanks,
Maria

https://cgit.drupalcode.org/d6lts/plain/common/core/SA-CORE-2018-001.patch

We are using Varnish and Pressflow (v6.30). Every time we flush cache in Pressflow, we encounter problems where browsers can not get requested CCS/JS aggregate files as they do not exist. We have found that if we flush Pressflow cache and then immediately flush varnish cache, problem is fixed.

Anybody else had this issue? And is there a module (purge or similar) which automatically handles Varnish flush cache with Drupal cache?

In includes/file.inc line 517 the following code takes care of handling the errors if something has occurred during file upload.

if (isset($_FILES['files']) && $_FILES['files']['name'][$source] && is_uploaded_file($_FILES['files']['tmp_name'][$source])) {

The issue is that if the PHP upload limit is reached the is_uploaded_file() function will return false and the error will never be returned correct to the user. The user gets an error, but just an message that the image could not be uploaded - not the "file is too large"-error. The is_uploaded_file() function should not be in this if-statement.

Perhaps $_FILES['files']['error'][$source] should be checked first as testing show that it gives a proper 1 as a result.

There are multiple patches for this, but it has never gotten into the master branch for drupalistic reasons. https://www.drupal.org/node/30520

drupal core issue: http://drupal.org/node/883038
patch: http://drupal.org/node/883038#comment-4554420

here's the commit: http://drupalcode.org/project/drupal.git/commit/ae71f5d
actual patch to core: http://drupalcode.org/project/drupal.git/patch/ae71f5d

only tested with drush make like this:

projects[pressflow][type] = "core"
projects[pressflow][download][type] = "get"
projects[pressflow][download][url] = "https://github.com/pressflow/6/tarball/master"
projects[pressflow][patch][] = "http://drupal.org/files/issues/ereg-suppress_warnings-883038-drushmake-clean-D6.patch"

home this is remotely helpfull

While upgrading to 6.38 I saw that the following line changed from extract(parse_url(urldecode($destination))); to extract(parse_url($destination));. Is there a good reason for that? Because it doesn't seem to be a backward compatible change. It breaks some of my urls such as; destination=page%253foo%253D10%2526bar%253D20.

I have created the pull request #109 in case that change make sense.

Looks like 6.27 has been released due to a security vulnerability.

http://drupal.org/SA-CORE-2012-004

I just downloaded and installed Pressflow 6.23 around noon, Feb 15th, onto a fresh install of Windows Server 2008 R2 and a secure variant of WAMP called the Uniform Server.

Looking at the log after installing, right after the "Action 'Ban IP Address of current user' added" log entry I see about 25 error entries:

Message: Notice: Undefined index: in update_xlm_parser->end() (line 256 of ...update.fetch.inc).
Severity: error

The same message is repeated for all 25 log entries marked as error.

I tried running the update.php script to see if that triggered the error message again, but it did not.

Hi All

I am working on deploying/installing pressflow 6 on ppc64le architecture. I am using Ubuntu 14.04(trusty) on top of ppc64le hardware, while installing pressflow6 I am facing below warnings, which interrupts the installation process.

• User warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') ORDER BY fit DESC LIMIT 0, 1' at line 1 query: SELECT * FROM pf_menu_router WHERE path IN () ORDER BY fit DESC LIMIT 0, 1 in _db_query() (line 170 of /var/www/drupal/includes/database.mysql.inc).
• User warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') ORDER BY fit DESC LIMIT 0, 1' at line 1 query: SELECT * FROM pf_menu_router WHERE path IN () ORDER BY fit DESC LIMIT 0, 1 in _db_query() (line 170 of /var/www/drupal/includes/database.mysql.inc).

For more information I have attached snapshot of warnings along this post.

Below are machine details which I am using,
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.3 LTS
Release: 14.04
Codename: trusty

$ uname -a
Linux test-local-machine-1 3.19.0-15-generic #15-Ubuntu SMP Thu Apr 16 23:32:13 UTC 2015 ppc64le ppc64le ppc64le GNU/Linux

Any pointers/suggestions on above warnings will be great help.

Simply applying the change from SA-CORE-2014-002 doesn't acctually work on pressflow.

The cause is that function page_get_cache() is different than core, and instead we need to use the pressflow-APi addition drupal_page_is_cacheable() which will make the change more similar to the SA fix for Drupal 7

Guess this is more of a support request then an issue, however it is specific to pressflow, with vanilla drupal we don't have this issue.

For one of our sites we have this setup:

varnish
apache + mod_fastcgi + php-fpm
memcache
php-apc
pressflow 6.26

After a cache clear all form the interface things get really funky. Basicly a page request takes about 1 minute! After a while things normalize and the frontend starts to perform as it should again. There are some steps to increase this (load the frontpage, restart memcached, force a theme registry cleanup by visiting /admin/themes). We don't have this problem with normal drupal 6.26.

I'm having problems debugging this. I installed devel module and configured it to use xhprof on my dev server (same setup) but it shows nothing out of the ordinary, that is wall time is at most a couple of seconds not one minute or more. Please assist, as said the problem is specific to pressflow but to be fair also for this specific sites theme.

It looks like 6.24 is already out and I was wondering if Pressflow is going to update to that soon or wait until more testing is completed? If you look at the release page:

http://drupal.org/drupal-7.12

It says about 6.24 that "these might need a bit more testing before deployment"

Thanks!

[Security-news] SA-CORE-2014-002 - Drupal core - Information Disclosure

Was just released. We should merge that and make a release

In Pressflow 6.25 if $db_url is an array, simpletest fails in at least a couple ways.

It produces temp tables of the form and then can't drop them later:
Arraysimpletest12345access
Arraysimpletest12345actions
...

Calls to variable_get(), variable_set() fail.

The following code in my test set-up works around the problem:

public function setUp() {
// simpletest doesn't like array-valued $db_url.
global $db_url;
$default = $db_url['default'];
$db_url = $default;
}

module_hook adds excessive function_exists

Hi,

Is it possible to release new version of pressflow6 based of drupal6.49?
This version has better PHP 7.2 support.

Thanks!

Drupal introduced a 6.36 security release today, but I don't see a corresponding release for Pressflow.

For those of us building sites using drush_make files, would you be able to tag the merge commits for each version? It would be really helpful, and might help avoid confusion from people attempting to use the DRUPAL-6-xx tags. I eventually realized the issue, but it wasn't that intuitive :)

Cheers!

Drupal bug: http://drupal.org/node/943572

Latest Drupal code:
http://drupalcode.org/project/simpletest.git/blob/refs/heads/6.x-2.x:/drupal_web_test_case.php#l3108

Patch for Pressflow 6.26

Index: modules/simpletest/drupal_web_test_case.php
===================================================================
--- modules/simpletest/drupal_web_test_case.php (revision 7131)
+++ modules/simpletest/drupal_web_test_case.php (working copy)
@@ -2624,10 +2624,12 @@
   if ($original_file_directory) {
     $file_directory = $original_file_directory;
     $class = $test_class;
-    $verbose = variable_get('simpletest_verbose', FALSE);
-    $directory = $file_directory . '/simpletest/verbose';
-//    return file_prepare_directory($directory, FILE_CREATE_DIRECTORY);
-    return file_check_directory($directory, FILE_CREATE_DIRECTORY);
+    $verbose = variable_get('simpletest_verbose', TRUE);
+    $directory = $file_directory . '/simpletest';
+    file_check_directory($directory, FILE_CREATE_DIRECTORY);
+    $directory = $directory . '/verbose';
+    $writable = file_check_directory($directory, FILE_CREATE_DIRECTORY);
+    return $writable;
   }
   return FALSE;
 }

Hi,
i have to thank all of you for this great work!!
I have updated from 6.24 to 6.25 some test site i have, and found that bug #1425868[1] is already present.
Is it already present even in Drupal 6.25 ?

Thanks :-)

[1] http://drupal.org/node/1425868

Hello,

In the file drupal/includes/unicode.inc at line 339 the path is wrong :
include_once './includes/unicode.entities.inc';
because the file unicode.entities.inc is in the same directory.

I think that the good path is :
include_once 'unicode.entities.inc';

Jerome

... should? ...would?

http://drupal.org/node/76824?page=1#comment-6219222

patch: http://drupal.org/files/fast404-76824-351.patch

When using Drush the cookie_cache_bypass module doesn't need to do the setcookie() command.

Drupal was updated to v6.30 last Wednesday, any plans to merge in the changes? Thanks.

We increased our drush usage on all drupal projects. When drush pm-update command is used to update a Pressflow instance, it would update it Drupal vanilla, rather than the latest Pressflow release.

I looked into Drush code and documantation and also the Pressflow code changes. Apparently Drush's behavior is normal, since it checks the update status via installed Drupal/Pressflow instance's update.module

Honestly I was expecting Pressflow would patch update.module with Pressflow's update notification service URL for the core, and the default for the contributed modules and themes. So that Drush would work as expected and update Pressflow, rather than replacing it with Drupal vanilla.

Is there any plan for near future to make this kind of of a change? Or is it against Drupal policies?

Thanks,

Osman

See https://bugs.launchpad.net/pressflow/+bug/531108
I wonder if there's a patch for this issue or any progress in that direction. I found that is related to http://drupal.org/node/1011614 and it's still an issue.
Thanks

Backport $language_url from D7. Example situation

node language: el
user language: en
pathauto creates aliases in lang el (same as node)

expires module requests url() to get aliases of node path, does not get right results because path_alias_cache uses global $language instead of $language_url. Had to h ack expires module to set $language to node's language, then reset.

Hi there.

After upgrade to 6.27 we got:

"Fatal error: Call to undefined function db_connect() in [...]/includes/database.inc on line 166"

Pressflow 6.27, the latest Domain module.

All other non-Domain Pressflow sites work fine.

Ideas?

Szy.

I am get an optimization suggest every time I run my website thru gtmetrix.com (pagespeed generated suggetion). The problem is that the user profile pictures don't have any size specified in them. While googling for it I found the following links:

http://drupal.stackexchange.com/questions/4131/better-performance-by-putting-image-dimensions
http://drupal.org/node/1129642#comment-4411506

It seems like this was fixed in D7, but not D6. Is there any plan to include this in Pressflow?

cookie_cache_bypass.module and path_alias_cache.module are not mentioned anywhere. There should probably be an explanation for them and when to use them.

Thanks to both Drupal's session handling when logging out (https://drupal.org/node/754560), and the session-free nature of Pressflow, there are several scenarios where a user does not see the message being saved by core:

• User deletes their user account (via user_delete module).
• User requests their password be reset.

Pressflow should extend core to provide logic that allows these user messages to be displayed.

I am unable to use any aspect of my site with multi-step forms.

Deleting nodes from 'admin/content/node/' does not work, uninstalling (not disabling) modules does not work either.

Also, any modules providing multi step forms fail, in that once I reach the submit button for the form I am taken back to the beginning page of the form with a message that I did not select any options on that forms first page.

Any ideas would be most appreciated.