Problem/Motivation

PHP Fatal error: Undefined class constant 'REDIS_DEFAULT_HOST' in redis.admin.inc on line 30

Proposed resolution

Remaining tasks

User interface changes

API changes

CommentFileSizeAuthor
#1 php_fatal_error-2478943-1.patch3.28 KBjoelpittet

Comments

joelpittet’s picture

joelpittet
he/him
Primary language English
Location Vancouver
commented
Status: Active » Needs review
StatusFileSize
new php_fatal_error-2478943-1.patch3.28 KB

There are a few of these since the latest changes, here's a fix for a couple of these FATALS.

joelpittet’s picture

joelpittet
he/him
Primary language English
Location Vancouver
commented

May want to open a 3.x-dev branch to help test debug these changes. Just a suggestion because I know I'd be on those to help find them (addicted to updating) before a stable release.

pounard’s picture

pounard
Primary language French
commented

Ouch I thought I fixed that one, thanks for reporting!

pounard’s picture

pounard
Primary language French
commented
Status: Needs review » Fixed

Commited and fixed, thanks!

  • Pierre.R committed c781cdd on 7.x-3.x authored by joelpittet 
    Issue #2478943 by joelpittet: PHP Fatal error:  Undefined class constant...
joelpittet’s picture

joelpittet
he/him
Primary language English
Location Vancouver
commented

Thanks for the quick fix @pounard!

pounard’s picture

pounard
Primary language French
commented

I also created a dev release, I probably won't do it too often since I'm not used to, but I'll try. Thanks for suggesting it.

joelpittet’s picture

joelpittet
he/him
Primary language English
Location Vancouver
commented

@pounard It's interesting to me why or why not people use the dev branches. Sometimes the better version of module is in the dev branch and has been for years... which should get a release. Although other times there is no dev release and everything is done on the master branch.

mailchimp module is the other one that comes to mind that did the new stable version for most changes so their 2.x was a bit of a buggy stable release for a while.

pounard’s picture

pounard
Primary language French
commented

If you want to use a dev version, you should clone the repo instead, the fact that -dev releases are made only upon a manual action from the developer explains why the -dev releases are not universally up to date. That is exactly why I never do them, I don't understand why the build system don't package itself nightlies like every other open source project is doing since the year 1812 (at least).

joelpittet’s picture

joelpittet
he/him
Primary language English
Location Vancouver
commented

OH, I see. I need to get a better workflow with git submodules or something... I pull down -dev releases with drush and store in the git project so that my modules and their patches are stored together in the same repo. And drush up like a crazy person.

I thought dev was doing nightlies, or at least it seemed so from some of my work on menu_attributes. (All I remember is committing to the 7.x-2.x branch and the dev would mangically show) I could be remembering wrong, it's been a while.

pounard’s picture

pounard
Primary language French
commented

Hum actually I might be wrong, let's await a few days and see if the -dev release auto-updates.

pounard’s picture

pounard
Primary language French
commented

I am very sorry I got it all wrong, as https://www.drupal.org/documentation/releases/types states, the -dev release are automatically built when the system detects pushes on the dev branch. I don't know why I got it wrong, maybe I experienced hiccups on some projects in the past.

So, you can plug on the -dev releases, that's OK, it will be automatically built.

joelpittet’s picture

joelpittet
he/him
Primary language English
Location Vancouver
commented

Thanks @pounard, it is not without hiccups but thank you for checking into that.

I'm plugged in;)

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.