Like others, we need to run the D7 version of the notifications module on top of PHP 5.2. That's the only version available in our hosting environment.

Any idea when this will be tested/support?

Jim

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jcsalem’s picture

Title: Enhance latest version of Notification module to support PHP 5.3 » Enhance latest version of Notification module to support PHP 5.2
spacereactor’s picture

I bump at first that Notification require php 5.3, but after spending some time upgrade my server to php 5.3 and it does pay off alot, drupal 7 overall speed increase. And i do understand that many can control which version of php their host provide.

Dane Powell’s picture

Title: Enhance latest version of Notification module to support PHP 5.2 » Notifications / Messaging PHP 5.3 requirement
Category: bug » support

I think there's still some debate over whether this should be a requirement, or whether we should make the packages compatible with PHP 5.2. Let's focus any debate/discussion in this issue.

Jose made it clear that he wanted 5.3 to be a requirement, and I'm inclined to agree. However, neither of us is really maintaining this package any more, and if 5.2 can be supported to no detriment of 5.3 users, I don't see why that's a bad thing.

Kisugi Ai’s picture

the problematic is follow
the most Hostprovider haven't jet PHP 5.3
because about of some old customer script compatibility and the PHP 5.3 are relavie new.
so the privider have a big problem to swich to the new php release.
but the most of providers work on an implementation of php 4.4, 5.2, an 5.3
so we have to spend some time of patience but some of us can't wait so thats the question came up why 5.3.
;)

@jcsalem you can try to comment out the line "php = 5.3" in the info file may be you have luck and it works.

bryancasler’s picture

I'm on rackspace's cloud sites. They are using php5.2 and when I asked support if they have plans to upgrade they said they did not. Just something to consider.

bryancasler’s picture

subscribe

anavarre’s picture

Subscribe

cwgordon7’s picture

Category: support » task
Status: Active » Needs review
FileSize
5.88 KB

This patch works for me on php 5.2, although it's possible I missed something somewhere. It changes the API ever so slightly, requiring the caller to pass in the classname. I left in a compatibility layer for developers who are using php 5.3, so they can continue depending on get_called_class() in their own modules, but I changed notifications core to pass in the class name. It's really a very small change and would mean that a lot of people who are stuck on php 5.2 for various reasons could use this module. Please consider committing this patch. Thank you!

geek-merlin’s picture

cwgordon7’s picture

Actually, the aforementioned patch uses debug_backtrace() and which is quite slow and runs preg_match() on the results which is not at all elegant. debug_backtrace() should really only be used for debugging purposes, which is in fact its intended use.

zeezhao’s picture

+1. Please confirm which patch we should be using. Thanks

mefisto75’s picture

sub

mike503’s picture

Priority: Normal » Critical

I definitely +1 this.

If I knew how to accurately test this, I would help. It seems like the patch has the right idea, and I would try to lend my PHP expertise to this, but I don't really touch OOP code (personal belief against it in PHP :))

Seems like it isn't too difficult, just passing an argument to the methods instead of trying to use get_called_class() magic...

I don't know how else to help exactly. I could try to do the same thing the patch would do, but I wouldn't know whether or not the functionality is fully working or not :p

While I would love everything to be 5.3, it's still not realistic, sadly :( Especially for those people on shared hosts. They have it even worse.

sapguroo’s picture

Hi Can some one let me know how to apply this patch please, I am new to this

Kisugi Ai’s picture

take Installing Git or using linux and look at "versions control" how do "git apply -v [patchname.patch]"

Corbey’s picture

Sorry to be annoying, but is this patch for 7.x-1.x-dev? I put it in the Notifications folder and try to apply the patch but it won't work. Am I putting it in the right place?
I'm getting a "Patch does not apply" message.

zeezhao’s picture

re #16:

yes it is for 7.x-1.x-dev. I used the one in #9 though, placed it in the notifications folder and it worked.

Corbey’s picture

thanks for the heads up!

Kisugi Ai’s picture

hm i have apply the patch of #9 but i get

Strict warning: Static function Notifications_Object::object_load() should not be abstract in _registry_check_code() (Zeile 2913 von /var/www/includes/bootstrap.inc).

3 times
the patch from http://drupal.org/node/1055454
does not work
any idea?

webflo’s picture

@Alyx this error is fixed in #1055454: Strict error reporting warnings. Download the lastest Version from git or wait a few hours for a new development snapshot.

r0bm1lls’s picture

HI guys,

Tried applying patch in #8 and #9 on latest 7.x-1.x-dev release patch does not complete properly. Has something changed?

Thanks for all this work for us php 5.2.x guys.

Ami doing something stupid?

Result - patch in #8
patching file notifications.admin.inc
Hunk #1 FAILED at 10.
Hunk #2 FAILED at 396.
2 out of 2 hunks FAILED -- saving rejects to file notifications.admin.inc.rej
patching file notifications.info
patching file notifications.list.inc
Hunk #3 FAILED at 654.
1 out of 3 hunks FAILED -- saving rejects to file notifications.list.inc.rej
patching file notifications.manage.inc
Hunk #1 FAILED at 79.
1 out of 1 hunk FAILED -- saving rejects to file notifications.manage.inc.rej
patching file notifications.module
Hunk #1 succeeded at 1294 (offset 18 lines).
Hunk #2 FAILED at 1432.
1 out of 2 hunks FAILED -- saving rejects to file notifications.module.rej
can't find file to patch at input line 107

Result - patch in #9
patching file notifications.info
Hunk #1 succeeded at 3 (offset -1 lines).
patching file notifications.module
Hunk #1 FAILED at 1415.
1 out of 1 hunk FAILED -- saving rejects to file notifications.module.rej
can't find file to patch at input line 57
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git notifications_scheduler/notifications_scheduler.info notifications_scheduler/notifications_scheduler.info
|index aa38605..459a2e4 100644
|--- notifications_scheduler/notifications_scheduler.info
|+++ notifications_scheduler/notifications_scheduler.info
--------------------------

Rob

naught101’s picture

Same happened to me, most of it is due to new lines and other crap (most of the patch applies). Here is a re-roll against the git 7.x-1.x branch

r0bm1lls’s picture

Great I'll give it a go thanks..

Hope this actually gets into the real thing otherwise we are forever patching and updating.

Everett Zufelt’s picture

Curious if this patch will get committed to 7.x-1.x-dev.

If it is an issue of testing I can patch and test. If there is another reason for not allowing the module to work on PHP 5.2 then I would like to know so that I can better inform my client about their options:

- find another set of modules to satisfy the use case
- hack the module
- try to persuade the host to do an upgrade to 5.3 (unlikely)

BarisW’s picture

Just as a heads up: for those who use Acquia Dev Cloud, they are unable to use the Notifications module with this requirement. Removing this requirement would be very nice ;)

MatthijsG’s picture

It's not clear to me, if it's clever to tweak this module to work with 5.2. When using patch from #9, what are the drawbacks?

And is #9 enough to work this module with 5.2 or do i need #22? In #22 several files are modified, including the notifications.info.

rooby’s picture

The patch referenced in #9 is basically a hack, whereas the one on #22 is trying to fix the problem properly.

I would not recommend the approach taken in #9 and it would have performance implications, as has been mentioned earlier in this issue.

Please test the patch in #22 if you can - it would be great to get this in.

rooby’s picture

I have just started using the patch in #22 and everything is good so far.
I will report back in a couple of days whether I run into any issues.

chuntley’s picture

Rooby, did it work?

rooby’s picture

The patch worked fine it seemed.

However I found the Notifications & Messaging suite too buggy for my needs at this point and I don't have any time left in this project for bug fixing so I switched to the subscriptions module.

So I haven't tested it extensively.

IreneKraus’s picture

I see under the status for the module that a new maintainer is being sought. Maybe once this occurs we'll see some progress on this and the many other issues that have not been addressed. Though I wish I could be of more help in that sphere, I know my knowledge of PHP/Drupal coding is not up to par. I've been too ill over these past few years to learn how to do that, but (crossing fingers) those things seem under control. So, what I'm working on doing now is how to integrate patch suggestions on my test server so I can provide better feedback. At least then I'll be contributing something back into the community!

strager-1’s picture

Could someone provide the updated files in a format other than .patch? I've never been able to successfully install one of those, and my provider won't let me upgrade to the higher version. I'm at 5.2 and this is a dependency for several essential modules.

RKS’s picture

You could always apply the patch manually. For those of us who are religiously intolerant of git it's all the rage.

RKS’s picture

As for the discussion at hand, it looks pretty clear the maintainers are opposed to committing any patches since that would potentially affect the 5.3 users. As stated above, that is their major concern. I'm always one for the people and from that standpoint I would have to agree with making this module compatible with 5.2. Many people are on hosts and those hosts don't want to upgrade to 5.3. Ask any host using 5.2 and you'll get the same answer. I too am in the same boat since my host is running 5.2. I only ended up here after traveling the long and winding Mailhandler/MailComment modules gauntlet of dependencies. Alas, a module with so many dependencies is another problem altogether so I won't waste your time complaining about the last hour I spent downloading dependent module after dependent module only to get here and find out that long process was for naught.

So yeah, a 5.2 commit would be nice or at least make your MailComment module stop being dependent on Notifications since you're too good for us hosted folk.

rooby’s picture

You could always apply the patch manually. For those of us who are religiously intolerant of git it's all the rage

You don't have to use git to use patches.

You can use the 'diff' command to create patches and 'patch' command to apply them (or whatever the windows based equivalent is if you are that way inclined).

For example,
patch -p1 < patch_file_name.patch

RKS’s picture

I'm really not against git, especially not religiously biased since that doesn't even mean anything. I was just joking with the guy. I use git all the time.

IreneKraus’s picture

I've just finished switching one of my sites over to using a different system (Subscriptions) so that one is one step closer to an upgrade to Drupal 7. My own site, however, makes use of Organic Groups so as to organize discussion by project. All of my clients want e-mail notifications for when new posts should occur, and - so far as I know - this is the only project that provides support for that. (Hosting company, like many others, will not use 5.3 branch of PHP due to conflicts with other web software.)

The reason I'm adding another comment into this queue is to say it will be a while before my sites, including my own, are 100% ready for that Drupal 7 upgrade. If it looks as though things are moving along with this module by the time all of my other upgrade challenges are resolved, then I will have to do something so as to maintain this function on my site. I've gotten a few ideas from other discussions, but for now things are in a holding pattern. Hopefully when I reach that milestone to upgrade, some new maintainers will be in place and we'll see some progress. (I'm more a designer than a PHP programmer, but I'm having to learn that just to do theming!)

RKopacz’s picture

Just curious if there is any final word on the PHP 5.3 vs. 5.2 question. Will the maintainers provide support for PHP 5.2 or not? Has a decision been made? Or are they still pondering it? Not complaining, mind you, just wondering if a final decision has been made. I am also a hostage to various commercial hosting companies, who show no inclination to update to 5.3 in the near future. I would like to use this module, but just wish to know if the maintainers have made a decision one way or the other.

zeezhao’s picture

It would be great if the patch is committed to git, as php 5.2 is still needed by many... Thanks.

kevster111’s picture

Priority: Critical » Normal

Just curious if this is still an issue. Keeps me from using drupal 7 on sites I run that use notifications. Still don't see anything on the Notifications page that says php 5.3 required.

I know its not the developers problem, just asking. If not do the patches above still work?

kurtzhong’s picture

Seems like even i use 5.4.7 i still can't get this module working. What a headache. So much code to debug.

DamienMcKenna’s picture

Issue summary: View changes
Status: Needs review » Closed (won't fix)

Both PHP 5.2 and 5.3 are unsupported, so I don't see any value in committing this.