In various threads, like http://drupal.org/node/56972 and http://drupal.org/node/43712 there is very intense discussion about how to patch a problem with paths.module that causes sites with a lot of path aliases to eventually slow to a crawl as more and more paths are added.
I have one of those sites. It is a growing number of path aliases generated by path auto, and it is slowing down.... I need this fix. How do I fix it? I see various patches posted in these threads, but I also need to apply 4.6.6 for security reasons. I note that there will be no upgrade to the 4.6.x Drupal. One of the Drupal Gods (Killes? Dries?) dropped in on one of the threads briefly to point out that 4.6 is frozen. Well a lot of people are still choosing Drupal 4.6 to deploy right now, since 4.7 isn't done and the modules haven't nearly caught up with the core.
Apologies if this has become a non-issue since April 3rd when the last post on 56972 was made, but I don't see a resolution, and the community as a whole should know about this problem before choosing Drupal 4.6.x if it isn't going to be fixed. Path alias is an important component. The fact that it will eventually choke your site isn't widely known.
Thanks
Comments
This will not be backported
This will not be backported to the 4.6 branch. Drupal 4.7 ill be released soon and we recommend that you upgrade as soon as this happens. We also invite you to try our release candidate to make sure your update is aas smooth as possible.
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
It's a shame that the
It's a shame that the solution will not be back portede to 4.6. We also have been experiencing similar problems. While we want to move to 4.7 that is not a practical choice in the short term. We have live sites and a huge amount of testing will be required before we can deploy 4.7. We have custom modules as well as the base installation on 4.6.
Second that.
There are many sites that will have to spend 3-6(+) months to prepare for, test, upgrade competence and customisations, etc. before a 4.7 upgrade is possible to do sufficiently safely.
.
--
( Evaluating the long-term route for Drupal 7.x via BackdropCMS at https://www.CMX.zone )
Third that
I have about 46 non-core modules. At least 12 are not available (yet) for 4.7. At least 3 look like they will never be available for 4.7 so i have to decide whether to regress the functionality or port/rewrite them myself. And 11 more are written by me. Sorry Killes but you can't just casually say "go 4.7". I sold software for 20 years and we back-supported at least 2 releases and/or at least 2 years. i think most of us understand that drupal.org does not have the resources for that (and aren't collecting the obscene support fees we used to for our software). You need to recall that changing releases is months of work for a site like mine, once all the module are there. Heck I only got 4.6 live last week :-D
On the particular issue of this patch I'd say if it is that important to folk: pitch in and port it yourself or pay someone to do the port. We can't expect Killes and three others to do everything on free software.
Sorry, but I am not really
Sorry, but I am not really interested in how much work you have to do to get 4.7 up and running on your site. You already found the difference between your software company and drupal.org: money. So we don't get money, but we are also free not to care. Fair deal as far as I am concerned.
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
I'm curious as to why this was decided
It is, after all, a *bug* in the 4.6 architecture. What's the rationale behind not backporting it?
- Robert Douglass
-----
My Drupal book: Building Online Communities with Drupal, phpBB and WordPress
Exactly. One can understand
Exactly. One can understand the philosophy of 'feature-freeze', but a bug?
It is quite debatable it it
It is quite debatable it it is a bug. But let me rephrase my statement: I will not backport it to 4.6. I won't commit anything to the 4.6 branch sans security related issues.
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
So, the door is open?
Killes, you must recognize that there will be hundreds, maybe thousands more deployments using 4.6.x before people use 4.7. Modules are not ready. Also, there are countless Drupal sites out there that may eventually be suffering from this problem. Think particularly of all the CivicSpace implementations with huge membershps and therefore potentially large paths collecxtions. Nobody with serious experience likes to be an "early adopter". I have been building websites for twelve years and there's no way I am about to start developing a site for a 55,000 membership org (my current contract) using 4.7. Maybe in a few months. Probably six months out. So you can tell people all you want to upgrade the 4.7 and use 4.7 for new sites. In the real world that won't be the case for people like me.
So, when you say I will not... does this mean some other kind soul may take the initiative and see that this serious problem gets fixed in the core distribution? I would say Drupal's reputation depends on it. As these sites grow, the problem will be come more prevalent and Drupal will be more and more known as that slow CMS.
As excited as you guys are about 4.7 and all the great improvements (there are too many to mention and I love it) it is absolutely required that you keep the legacy healthy by either fixing this paths.module bug or telling people why their sites progressively slowing down is not a bug but a feature of Drupal 4.6.
I want to be a farmer.
There are currently four
There are currently four active core committers, it is possible that one of the three others will commit this. I doubt it, though. The backported patch is freely available and nobody will inhibit you from applying it to your 4.6.6 install.
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
Certainly...
I will apply the patch to my 4.6.6 sites...once I see one for 4.6.6. The current thread on the subject http://drupal.org/node/56972 trails off and comes to no conclusion as to which patch people should be applying to 4.6.6. The "money" patch for 4.6.5 seem to be http://drupal.org/files/issues/path_alias_backport2.patch, but work on figuring out which patch will work for 4.6.6 has not finished and no new messages have been posted for ten days.
If no core committer will commit this patch, then there seems to me we are in need of an intermediary zone where critical patches like this can live next to clear instructions on how to apply them.
This one specifically could live at http://drupal.org/handbook/modules/path along with some copy that read:
If you intent to use the path module to create a large number of paths, then you should apply this patch to your Drupal 4.6.x site: http://drupal.org/files/issues/path_alias_backport2.patch
I still maintain (and this is supported by the reported performance gains post application) this is serious enough to be committed, and continuing to allow people to deploy with 4.6.x with this bug lurking off in their high n path alias futures is not a good idea at all.
Finally, what does the application of this patch do to the 4.6.x ->4.7 upgrade path? Will the 4.7 upgrade break and leave people who patch in the lurch?
I want to be a farmer.
To your last question
The patched files are replaced wholesale in the 4.7 upgrade, so no, you should not have any problem there.
Laura
_____ ____ ___ __ _ _
design, snap, blog
_____ ____ ___ __ _ _
Laura Scott :: design » blog » tweet
Thanks
That makes the option to patch more attractive.
I want to be a farmer.
The patch is not in all
The patch is not in all cases an improvement. I you use pathauto or just have a lot of aliases ddefined, it sure is an improvement. If you however have only a few paths defined, it will probably slow your site down, since now
a (very inexpensive) database query is made per url in the generated page.
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
so on a site with a lot of
so on a site with a lot of menus and blocks with links that inexpensive query adds up to a lot of queries per page load. does drupal's caching mitigate that or are these queries not cached?
I want to be a farmer.
These queries (or rather
These queries (or rather their results) are cached if the page is cached (ie for anonymous users). The results are not cached for authenticated users. The results might be cached by mysql's query cache, though.
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
What makes 4.6 and the patch
What makes 4.6 and the patch so different form 4.7? Does 4.7 have the patch code in it? Has something entirely different been done to compensate for the problem in 4.7?
Well, Hiveminds claims to
Well, Hiveminds claims to have the patched files as a package. Here it is:
http://www.hiveminds.co.uk/drupal-4-6-updated-path-alias-files
Hiveminds patched files work (for me) under 4.6.6
Tonight I upated my CivicSpace sites to 0.8.3 (which is Drupal 4.6.6) and then renamed the three files that need to be patched (updates.inc, common.inc, bootstrap.inc) and replaced them with the files in the hiveminds distribution referenced above.
Everything is working fine and very snappy. Admittedly I did not test the sites extensively after updating to 0.8.3 and prior to replacing the patched files, but I assure you things are running far faster than they have in some time, and there appear to be no problems at all with using the hiveminds files against 4.6.6. Check for yourself at http://www.bcndpcaucus.ca/. This site used to have latency of ten seconds or more at times. There are about a thousand path aliases in the system right now.
So for those of you not comfortable with applying patches, test out the hiveminds distribution on your tst site and see if it works for you as well as it did for me.
Hivemids also includes a full 4.6.5 patched distribution, but it is rather worthless now that 4.6.6 is out.
I want to be a farmer.
Thanks for the feedback.
Thanks for the feedback. Most appreciated.
So, it appears Carl McDade (Hivemindz) is not all about ranting against Drupal (big, evil grin;-))
He still uses it. So he
He still uses it. So he still likes the overall software. There are several people that have had complicated starts with the community that are still here. Communications involves understanding and sometimes that understanding takes time. So it's all to the good that time has passed and tempers cooled.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
Thanks for that!
Looks very interesting. Thanks for posting.
I want to be a farmer.
Better patch
There's a new, potentially better patch at http://drupal.org/node/43712#comment-92496
--
Tips for posting to the forums.
When your problem is solved, please post a follow-up to the thread you started.
An Open Letter to Drupal ---4.6.5 Site Choked to Death
Hello,
Just a quick note. I am one whose site was eventually choked to death by the url path alias issue. Site just absolutely became paralyzed and made it impossible to navigate or configure the site any further. After approx 3 months of trying to fix, 3 months of going through the Drupal threads, 3 months of trying to get independent coders to assist, even with the offer of money for their time, with a site absolutely packed with income producing ads, I elected to dump the entire site in favor of a fresh start @ 4.7.
Their is not doubt about the the brain power of those behind Drupal, there is no doubt about the magic of all of those who contribute in the forums and module and of course who can complain about the fact that this most powerful CMS is open source. BUT, something is greatly lost when you have to spend three months just to get a sight up and going. There is something which nullifies the benefits when many of the great modules has crippling bugs out of the box.
Without critizing at all, without really putting anyone down, I think maybe the brain trust of Drupal show slow down a bit and look things over. For instance, now module should be permitted without absolutely ensuring that it is free of (fatal) bugs. Perhaps its too much to expect that programs will be free of all bugs. But the addition of any given module should not crash a site nor paralyze.
I have heard of bit of chatter as to what's next! 4.7 seems to be close to completion, and the chatter seems to be what's next. Shouldn't there be some surety that 4.7 is tight? Even 4.6.5 currently has some major issues which can essentially render a sight useless.
From the little that I have observed as a non programmer oriented business person, Drupal does have a very nice operating module, it just needs to be tightened down a bit. The power of Drupal nor its most valuable contributors does not need to be harnessed, just the organization module and the execution of the same needs to be tightened up a bit.
Some core group should be posted at the gate whereby no module contribution is entered/excepted unless, as a maximum, not minimum, the module is compatible with the Drupal core --- no exceptions. Further, when a bug has been identified, this core brain power should lead the charge to fix. Contributors could assist and even play a lead role here, but the core brain power, should preside over this process. There seems to be a shell of this type of core currently in place, but it seems that they are too busy and the quality assurance could be better.
In closing, everyone is thrilled about open and what a great development. However, so that the Drupal CMS can lead all other CMS's in terms of quality and effectiveness of the CMS, perhaps a reasonable "membership" fee of say $25 per year, per member could be instituted that would fund the core brain power in terms of compensating them for their time. Indeed, one of the most marvelous developments of open source is that there is no cost. However, if the product begin to suffer, then all begins to become a little counter productive. Further, one must consider that most of the developers and contributors have full time jobs during something else and you are a witness, it is very easy to spend 4-5 hours on the computer searching forum threads to solve one issue.
I believe that we can keep the true spirit of open source, open contribution, and open use while instituting a reasonable membership fee. Each member would then be entitled to utilize forum resources. Anyone who might think that this idea is out of bounds, please consider that the forum is a most value resource and has saved many, including myself on many occassions. But it is free. Many take there valuable time to contribute answers and fixes, but this is what contributes to alot of the haphazardness of the process.
In my opinion, it is far more valuable to have a CMS which works, instead of spending so much time trying to get it to work.
To go along with the membership fee, perhaps Drupal should consider products to place in the commercial arena (i.e. CompUSA, Best Buy, etc.--maybe even under a different brand name?). This could be done without moving away from the open source platform at all. By not doing it, Drupal is leaving money on the table which could serve to strengthen the core and service and resources in which the core could make available to its open source members. My premise here is that not everyone is aware, interested nor has the time to dig through the open source process. Many people simply prefer to purchase off the shelf, even if it can be retreived through open sources. Why leave this money on the table?
I am not a programmer, but I can contribute in other ways. As such, this is my take on the matter. Again, kudos to all, there is so much positive on the table.
Publishing
Paid services
Dear publishing,
I do not understand your letter (for example, what are 'forum resources'?).
I simply want to point out that Paid services are available; you can post in the Paid Drupal services forum or contact one of the people who provide drupal services.
--
Tips for posting to the forums.
When your problem is solved, please post a follow-up to the thread you started.
Mr. Heine- You are right as you so often are, but!
Mr. Heine,
You are correct. Paid services are available, but the proceeds generated from the performance of such service go directly to the individual(s) performing the service, not to Drupal or the Drupal core team. For the purpose of facillatating the needs of the core Drupal to better enable them to render support (accurately & timely) to the Drupal community of users.
You see, to ask for such, to expect such without a true consideration for the time which goes into it, expended by those who assuredly have other things to do, is really unreasonable by any member of the Drupal open source community.
Its about, if its possible, going to the next level as a CMS. Open source, whether Drupal or the others, have many, many, many positives. However, when the positives start to get outweighed by the negatives, it must be looked at closely, without bias or emotion. It is really not a personal matter or a personal assault on anyone.
We can all improve, we can all get better.
Love
Publishing
After approx 3 months of
It should have taken a competent coder about half an hour (and I am generous here) to apply the existing backport patch to Drupal 4.6 and run some tests. Something went wrong.
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
I am not a programmer
But I did figure out how to apply patches. I patched my sites that were suffering from this bug. They are now very speedy again. Plus the patched files are available for download as well. Check the thread further up for the link.
It is less than ideal that 4.6 "ships" with this problem, but there are many other things less than ideal about 4.6 as well.
I want to be a farmer.
Forgive Me!, but I am not a competent coder!
Hello All,
I stand bare before you all and admit that I am not a competent coder, in fact, I am not a coder at all, that is the whole point. Only speaking for those who are the same. Comments were simply made on behalf of the none coders out there and perhaps there are more then most realize.
Just desire to make the product, system and the process better for all. I am not ashamd of my 3 month odessy into Drupal, for today I know more then I did 3 months ago.
Personally, I think that I am falling in love with Drupal.
Departing in Peace,
Sincerely,
Publishing.
Applied Backport, didn't work!
Mr. Killes,
With all due respect, I did in fact apply backport patch and it did not work for my site as there was no marked improvement or improvement otherwise. It was only then, that we elected to just start afresh with 4.7.
Somehow, I wish I had access to your brillance in the area of Drupal at whatever your price is. Such a powerful platform which can be seen clearly by someone like me who knows as little as I do re Drupal, php, etc..
I am just a entreprenuerial business man, moving to conduct business, that's it. The sky is truly the limit for Drupal. It's just a matter of where do you really want to take it, and what do you really want it to be. For indeed, it could be more!
Love Your Friend,
Publishing
If there were no
If there were no improvements after the patch, then your issue is unrelated to the issue discussed here. Maybe your site's watchdog and accesslog tables weren't emptied? This would explain why the site got slower and slower over time.
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
Thank You! --- Can u shed any light on below 4.7 error messg?
Will have a look and make a mental note of this. I soon got to the point that our problems could be due to a number of different issues. This is why a fresh start seemed the route to take.
Killes, can u shed any light on below error messgs in terms of fix? A similar/exact issue also can up for others in 4.6. However, the bootstrap file (code) versions have changed so the same fixes are not really useful at this point as they cause conflict within current bootstrap. --- Also opened new thread on matter as it pertains to current 4.7 release.
======
Warning: conf_init(./sites/default/settings.php): failed to open stream: No such file or directory in /home/bfnnetwo/public_html/drupal/includes/bootstrap.inc on line 154
Fatal error: conf_init(): Failed opening required './sites/default/settings.php' (include_path='.:/usr/lib/php:/usr/local/lib/php') in /home/bfnnetwo/public_html/drupal/includes/bootstrap.inc on line 154
=====
Thank You for your time,
Publishing
I also get the same error.
I also get this error when copying one drupal 4.7 site from one url to another even after changing the settings.php file.
Simon
Please start a new thread
Can you please start a new thread with all the details?
--
The Manual | Troubleshooting FAQ | Tips for posting | Make Backups! | Consider creating a Test site.