We are pleased to announce that the Drupal 4.5.0 release candidate is available. A list of the major changes can be found in the CHANGELOG file. We fixed most pressing issues during the code freeze, so we'd like you to help polish this release and to help iron out the remaining issues: your comments on the stability, correctness and performance of this release candidate are more than welcome!
You can download the latest release candidate at:
http://www.drupal.org/files/projects/drupal-4.5.0.tar.gz
This package is rebuilt twice a day, so make sure to download a fresh copy every now and then to get the latest bug fixes. No new features or functionality will be added. Only bug fixes, documentation updates and small usability improvements will find their way into the release candidate and thus into the final Drupal 4.5.0 release. When Drupal 4.5.0 is released, upgrading from the release candidates to the final version should be a breeze.
Installation and upgrading
For instructions on installing or upgrading Drupal, please consult the installation documentation and the instructions carried out by the update.php
script.
Important upgrade notes:
- For the most trouble free transition, it is recommended that you first upgrade existing installations to Drupal 4.4.
- Several files moved (or got removed) so it is recommended not to copy the new sources over your existing installation. Any left-overs might cause breakage so make a backup and start fresh.
- For the same reason, it is recommended to disable contributed themes and modules before starting the upgrade process. Upgrade them afterwards. Also note that not all contributed themes and modules have been updated to work with Drupal 4.5.
- You have to create two SQL tables manually (
users_roles
andlocales_meta
) as per the upgrade script's instructions.
Support and bug reports
For support and bug reports, please consult the Drupal project page. Please use the bug tracker to file and track bug reports.
Developer information
Developers should be aware that custom themes and modules for Drupal 4.4 need to be updated to work with Drupal 4.5.0. If you maintain a theme or module in Drupal's contributions repository, or if you want to contribute to Drupal development, this is the time to update themes and modules. A list of changes with Drupal 4.4 can be found in the Module developer's guide and Theme developer's guide.
The DRUPAL-4-5 CVS branch will be created soon so we can pick up active development on new features. In the meantime all Drupal contributors are encouraged to focus on the pending bugs as well as on documentation.
Comments
My Checklist
The following are items I would like to at least have looked at before a final release. I realize that some of them may not get in, but discussion is always a good thing.
terrific!
this just made my day much better!
Congratulations!
Congratulations on the release everyone!
Drupal 4.5 is a truly remarkable community achievement.
Brian.
--
Brian.
Yeah, but we can do better fo
Yeah, but we can do better for 4.6 :)
It really is great. Drupal has again come a long way in a short 6 months.
Looks Fantastic!
Much more intuitive - Good Job!
One thing i noticed immediately: Why when you post a story does it no longer put the line breaks in?
Nick
Usability
Yes, we worked hard to improve Drupal's usability. We still have a long way to go though, so usability suggestions are much appreciated and can be submitted as feature requests.
If you have support requests,
If you have support requests, please do so in the support forums, or post a support issue in Drupals issue tracker.
The linebreaks are added, in a much more intuitive way. But you do need to set thefilters you prefer the, first.
[Ber | Drupal Services webschuur.com]
Great!
Thanks to all the contributers. This marks the point where I can give it a good workout.
Just wondering what type of bugs to report on? (obviously not feature requests at this stage). Would we still be concerned with small usability issues, or only 'broken' things?
Cheers,
Ross.
All bugs
Send all the bugs you find. If none of them could be fixed for the final release, they could be useful suggestions/ideas for the next release (or point release).
will do
My enthusiasm got the better of me. Reading over the post properly, I found out that it's all spelled out quite clearly.
Permissions
Looks good, like the tabs (I assume this is not just the theme).
There is something I don't know how to do:
When I create a new 'category', I should be able to configure the 'roles' I would like to access it.
So if Bob/pighandlers & Jane/chickenpluckers have access to uploads, Bob should be able to mark his pig-related submissions with 'pigstuff' category, so Jane cannot access them.
Does it do this?
Node access
New in 4.5 is node access handling. The core is capable of handling that, but there is no code in it to maintain the permissions. You need to install an access handler from contrib. That should definitely solve the problem you explained.
Access handler?
And that would be called what, and located where? 'Cos I can't find such a thing in the CVS contrib repository...
[Very much hoping this exists, since access control is the main thing Drupal's been lacking so far]
No modules are released so fa
No modules are released so far, but you can have a look at JonBob's sandbox :
http://cvs.drupal.org/viewcvs/contributions/sandbox/jonbob/node_permissi...
(at your own risk)
--
If you have troubles with a particular contrib project, please consider to file a support request. Thanks.
--
Drupal services
My Drupal services
Dang...
Ok, I have a small complain about the node_permissions. Actually it's the nodeperm_taxonomy permissions... I dislike the fact that they can see my tree... In my opinoin, as far as they are concerned (they being the people who aren't supposed to see it) it shouldn't exists. Security by obscurity. The reason I say this, is I have a particulur section of my website that can contain potentially offensive material, so to avoid a problem, I just remove it from out of site, out of mind. I'm still in the playing stages of the 4.5 version, but as far as I can tell Drupal seriously lacks good permission control. Which is what other CMS systems have, generally speaking. Now of course the reply "well, shutup and use them instead", I'd also like to explain why I chose Drupal over PHP-Nuke.
(1) Ease of use. For me and my people. PHP-Nuke and many others were a nightmare to configure and get going. I began working on my own CMS system, but decided it would take forever to get what I wanted. I found Drupal. I'm relativly pleased with it and have been able to patch it (one way or another) to get what I'm after.
(2) Licenses. PHP-Nuke (and some others) have some licenses that suck (to put it bluntly). I wanted something free / GPL. PHP-Nuke has some weird funky method...
(3) Easy to hack (code wise) such that I could add what I wanted. Mostly for minor adjustments and gui changes.
So... if Drupal could get some good permission control, I could suggest it for our knowledge base at work...
oh well... perhaps 4.6...
-----------------
"Our greatest glory is not in never failing but in rising every time we fall." -- Confusious
Node level permissions modules
Really, this has nothing to do with Drupal 4.5 or Drupal 4.6. The
nodeperm_taxonomy
module is maintained in the contributions repository, outside the core repository. This means that the module can be updated or extended for use with Drupal 4.5 and that the modules will continue to evolve/improve during the Drupal 4.5 lifecycle. Read: you can modify thenodeperm_taxonomy
module to your likings and have it work with Drupal 4.5.The reason none of the node-level permission modules are part of core is that there exist many different use cases/patterns for node-level permissions. As illustrated by your post, implementing a single module that covers all possible scenarios might be difficult. That said, the existing node-level permission modules are likely to cover most common use cases. Last but not least, I hope to include the most popular (or most flexible) node-level permission module in Drupal 4.6 so everyone is invited to help harness the existing node-level permission modules. They are not part of core yet because we want you to work on them.
forum topics on node level permisison
Is there a existing issue/forum discussion for this module? How people can contribute or work on node level permission module?
Work smarter, not harder!
jeff_vicedo@yahoo.com
jhefmv [at] gmail [dot] com
Work smarter, not harder!
Well, theres a project for mo
Well, theres a project for most contributed modules, which has feature requests, bugsreports etc. attached.
See http://drupal.org/project/Contributed%20modules for a list.
For the nodeperm_taxonomy module, there's none yet, but you can check it out from CVS (sandbox/jonbob/node_permissions).
HTH, Uwe.
--
My Drupal site: http://www.crazy-hacks.org
Soon to be drupalized: http://www.unmaintained-free-software.org
Term Access
The TAC (Term Access Control) module works beautifully for what I want, however this means I have to hack all the modules I have. I would like the next version or at least know what version will have this. At that point, I will begin offering my knowledge because I really don't want to have to patch every single time... on the other hand, if it ain't broke... 4.4.0 works good enough for me now... *sigh*
Looking back, asking for permissions is asking quite allot (well, without offering my help).
So... as it appears, I have to put up or shutup.
I shall start reseraching how I go about contributing...
I'm running in circles...
I don't think this is the forum to discuss this type of thing, I'll continue elsewhere (since this isn't part of the 4.5 release and will belong elsewhere)
-----------------
"Our greatest glory is not in never failing but in rising every time we fall." -- Confusious
The term_access.module was cr
The term_access.module was created by a single developer without much consultation with the Drupal community. I don't think the neccessary patches will be in core as the community has gone another way to provide similar functionality.
--
If you have troubles with a particular contrib project, please consider to file a support request. Thanks.
--
Drupal services
My Drupal services
yeah but
it is quite true that everyone is welcome to work on the contributed node permission modules. but there are problems which cannot be solved within that module, and i expect this poster has run across one of them. specifically, you cannot run private forums without those forums being listed in the forums overview page and in the 'select a forum' dropdown in the authoring form.
it turns out that fixing this bug is non trivial. see http://drupal.org/node/9746
Congratulations everyone
Trying out the RC now and am very pleased. Looks like a lot of usability recommendations went in. Looking forward to the node-based permissions.
PHP5
does it support php5 now?
PHP5 support
Turned out we didn't fully support PHP5 yet. It is mostly working though. We hope to fix the remaining issues (see bug tracker) shortly. Feel free to help.
How do I publish my module requests
I think we need a more intuitive way of getting people to contribute their modules
I see so many "How-do-I-publish-my-module-requests".
This has nothing to do with how Drupal works.
Maybe we need a very obvious link saying
"Submit your module" link. or
"How to submission howto" or even
"Drupal Module Howto"
I know that the Handbook explains everything on this, but a direct relevant link would go a long way. The easier the process is, the more modules we will see.
Just my 0.02 cents.
http://scriptdiary.com - http://01wholesale.com -
http://01foto.com - http://businessletters.com
Organizing information is hard :)
One hopes that contributors will take the time to read the Developers guide which contains this infomation. I am not a developer yet it took me 60 secs to skim through the Developers guide and find the relavant information (Yes, I did actually time myself :).
Devlopers Guide
-CVS Repositories
http://drupal.org/node/319
--Contributions Repository
http://drupal.org/node/321
---FAQ
http://cvs.drupal.org/viewcvs/contributions/FAQ.txt?view=markup
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
CVS
Can I use the latest CVS modules with 4.5? They are basicly the same thing aren't they?
Thanks
Mr Maggoo
Some will work, others will not.
Some will work, others will not.
Wow
It looks like Drupal 4.5 will come complete with all of the little extras that I was wanting! Now I can start the preparations to relocate my WordPress content...
I recently developed a script to translate all of the content (for 4.4). Looks like I may be able to put this into production soon!
Can you contribute the script
Can you contribute the script to Drupal dev? A built in standard for switching from Wordpress, MT, or forums like phpBB and vBulletin, really is a dealbreaker feature for a lot of us considering a complete switch to Drupal.
Language files and translators
Can someone explain what is going on with po files:
1) What is the difference between fr.po and all the new po files?
2) Which files do we translate, fr.po or the other ones?
Aidez à traduire drupal en francais: http://drupalfrancais.zapto.org
Thanks!
Italian translation
I'd like to complete the italian translation made by Max Danno (it's about 40% or so). But I don't know if I've to base my translation on his it.po, update it with all that .pot files found in drupal-pot-cvs.tar.gz (but if i update the it.po with a single .pot, poedit 1.3.1 makes the large part of the original it.po obsolete!). Is there a GLOBAL.POT file that sums all that strings, to use it to update it.po? Even general.pot obsoletes most of the translation... Restart from scratch? Don't tell me so, please...
Handbook: translator's guide
There is now a translator's guide in the handbook which explains the new system.
http://drupal.org/node/11130
need more than that...
if i try to update a big .po with any of that small .po that comes with the drupal-pot-cvs.tar.gz, poedit marks the large part of my already vastly translated .po as obsolete and removes those strings! All those little .po must be merged into a single file and use it to update the original translation. I made, from a command prompt in windows:
copy *.pot ..\bigpo.pot
and used this in poedit to update it.po, and it found about 300 new strings to translate, added to those not already translated and those fuzzy. This is good, not update the big .po from little .pots! Who the hell needs those little files? boh!
All this things are not in the translator guide...
Translatior's guide: insufficient
Dear drupal gurus, the translator handbook does not tell me enough.
1) Why is there a large fr.po file with the SAME strings as the little po files under contributions/translations/po?
2) When I translate, do I start from the file under contributions/translations/po or from the drupal-pot-cvs.tar.gz?
3) How do I deal with a translator that translates half a file, checks in the po file under contributions/translations and goes away with half the work done? Giving me to option to start from a possibly out of date drupal-pot-cvs tarball means duplication of effort... and I am very lazy ;-)
4) How do I make sure module developers produce or update their POT file and tells translators about it - is it part of the module developer process?
Please help!
Guide updated
I updated the guide a bit:
Unneeded confusion...
This brings only to an unneeded confusion and waste of effort...
This way, one cannot take a partial translated version to complete
it, but must redo all the work from zero, since there are not the
small single translated version of them... Again, who the hell needs
those small files? Why not make available directly the big one .pot?
Confusion: one big or many small?
I agree on a few things:
1) Having the one large file instead of many small files is easier for site admins when they need to load a language into their site.
2) Having many small files makes translation teams easier to manage by assinging one file per translator.
Where I think this could be improved is:
1) Don't put the large concatenated file along with the small ones, instead, have a seperate download for the large file. This way you don't mix up the work of the translators with what the end users/site amdin needs to download for a translation.
And so I conclude the same thing as Steven:
1) All translations should be done directly on the small files, and checked into CVS by he translators.
An automated process can then update the large file, which should be available seperately from CVS. So don't put the large file in CVS, make it a single file "language pack" kind of download.
Makes sense?
yes and no
make sense to have an easier translation effort, but it complicates life to someone wanting to complete a previous partial translation, having to redo all the work, since update the old big one with small ones doesn't work... So, tell me if i have to restart from scratch, and i'll reinvent the wheel... sadly, but i'll do...
Restart from scratch?
I don't understand what makes it such that one would need to restart from scratch... I checked in a partial translation of the book module in Drupal 4.4, and it was ported to both the book module po file and the large fr.po file, nothing was lost. Now all I have to do is work on the small files, check them in, and site admins can download the large po file to get the language. Also, other benevolent translators can get the small files off of CVS and continue the translation... Am I missing something here? Maybe if you describe your process I will see what you mean.
BTW, I am not a drupal developer, I just try to understand the correct process for contributing translations ;-)
solved
work was boring, but now i've all small files semi-translated and i can begin complete the translation. This is how I made from poedit:
when i finish translating, what have i to do? Send to anyone (who?)? CVS them? I've no CVS account...
re: solved
Pay special attention to the last paragraph here:
http://drupal.org/node/11130
Can someone move this thread to a forum about the translation process?
Translations forum
No but I just setup a translations forum so I suggest you continue the discussion there.
Large vs small files.
"An automated process can then update the large file, which should be available seperately from CVS. So don't put the large file in CVS, make it a single file "language pack" kind of download."
This is already what is being done...
Actually, there are still som
Actually, there are still some large po files around in the CVS repositories. I will remove those to reduce confusion.
--
If you have troubles with a particular contrib project, please consider to file a support request. Thanks.
--
Drupal services
My Drupal services
Pending critical bugs
Here is a list of critical bugs that need to be looked at.
Disable locale.module before upgrading
I've been unable to upgrade to Drupal 4.5 until I disabled
locale.module
.it was fixed later on, after
it was fixed later on, after you posted the issue...
http://drupal.org/node/11232#comment-13342
Zip Format
Has the Drupal team considered offering Drupal in the downloadable *.zip format? It would open the door to many who would give Drupal a try but decide not to bother since they would have to search for a windows program to unzip the tarball.
Winzip is perfectly capable o
Winzip is perfectly capable of unzipping gzipped files.
--
If you have troubles with a particular contrib project, please consider to file a support request. Thanks.
--
Drupal services
My Drupal services
You're right, but I'm convinc
You're right, but I'm convinced only very few people know that. I think it might be a good idea to build an additional
*.zip
distribution.Uwe.
--
My Drupal site: http://www.crazy-hacks.org
Soon to be drupalized: http://www.unmaintained-free-software.org
File a feature request then.
File a feature request then. Maybe add a bz2 distro, too.
--
If you have troubles with a particular contrib project, please consider to file a support request. Thanks.
--
Drupal services
My Drupal services
If someone can't figure out h
If someone can't figure out how to open a gzipped file with a program like WinZip or WinRAR, I really don't think they ought to be attempting a Drupal installation.
icon
I think the default icon showing a zip archive of a *.gz file in combination with the magic double click, are enough hints. that in combination with some remarks in the documentation ought to do the trick.--
groets
bertb
--
groets
bert boerland
I think thats not a good idea
I think thats not a good idea. zip is a bad (read old) compression method. Far better exist. So we use them instread. And its never late for users to learn a little.
[Ber | Drupal Services webschuur.com]
This is one of those geeky threads
I love this thread.
Drupal rules - and is really ruled by geeks.
This is one of those geeky threads that show why Drupal will probably never become yacms - or perhaps yacmsiftgp (yet another content management system intended for the general public).
Not everybody knows what you know. Allow a little room for that. In communication it is different than when you build a database or code a system. Redundant data are a MUST when dealing with people in flesh and blood. If you tell your girlfriend that she's beautiful - she'll be happy. If you tell her twice - she'll be twice as happy. There won't come a debugger and remove the second instance.
:-)
I love you all. I think this system really is something - and I promote it whereever I can.
If you want non-geeks to use the system. Make it easy for them. Make their decision supported by a lot of things that go this way.
Tell them that if they use windows and prefer .zip files to .gz files, they can download these technically inferior files from the site. They just have to go to the special sector of the site - intended for the clueless non-geeks who don't know s...!
:-)
Best
Gunnar
Dropping in from Langemarks Cafe.
As a Windows user and someone
As a Windows user and someone who is employeed supporting that environment, I think that maintaining the one compression format is a good idea. As someone who has done so, maintaining multiple distribution formats is a pain in the neck and in my humble opinion a bad idea.
I would suggest as an alternative to adding to multiple distribution formats and complexity to the project, that education is the more appropriate route. A note about how to extract tgz files with standard windows compression utilities would be a better idea. It would provide an opertunity for others to learn something new.
User education in the area of technology is almost always better then over simplification. The complexities of a CMS already raise the bar for any new user. Anyone contemplating the use of a CMS with the potential of Drupal already needs to be a 'power user' or willing to put the time and effort into becoming one. The benefits they personally gain from doin so for themselves generally has a better chance of returing to the community.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
I don't think supporting mult
I don't think supporting multiple distribution formats would be any pain at all. I'm pretty sure the tarballs are generated automatically from CVS, so there's probably no additionaly maintainer action required for building an additional distribution format.
My point is: If we can easily lower the hurdle (of getting/installing Drupal) for some users, why shouldn't we?
Uwe.
--
My Drupal site: http://www.crazy-hacks.org
Soon to be drupalized: http://www.unmaintained-free-software.org
The argument that people who
The argument that people who cannot unpack a tarball will not be able to install Drupal is a valid one.
--
If you have troubles with a particular contrib project, please consider to file a support request. Thanks.
--
Drupal services
My Drupal services
Someone has to write the scri
Someone has to write the scripts to provide the different compression format. To create the link in the appropriate spot. This will need to be done for Drupal core and all modules adding to the load on the host server. Someone will have to test that the generated modules are not corrupted.
I suggest again that 'lowering the hurdle' should occur in education, not adapting the existing model of software deployment. It is simpler and less error prone to maintain one distribution format.
I have provided these instructions at least once in the forums to good effect. http://drupal.org/node/8592
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
HTMLArea not working
I can't get HTMLArea to work. It stops at [HTMLArea: loading script 2/3] in the browser status bar. I use the Mozilla Firefox 1.0 preview release. Any ideas what might be causing this problem ? Anybody else who has the same problem ?
The INSTALL file isn't entire
The INSTALL file isn't entirely up-to-date on which files are absolutely required in the misc/htmlarea directory. I didn't take the time to find out exactly what was needed, but replacing my "minimal install" by the "full install" ( e.g. just copying all files from the distribution ) solved the problem.
You are not authorized to view this page error
I've tried unsuccessfully 4 times to do a fresh install of 4.5.0-rc and I keep coming up with the same 403 Error "You are not authorized to view this page". Initially, I followed the instructions from http://drupal.org/node/258, but used cPanel X to create the database and phpMyAdmin to import the database.sql file. Then, I followed the steps in http://drupal.org/node/11325 that incorporate the usage of phpMyAdmin.
Each time I tried to install Drupal, I deleted all files and started anew. Not wanting to repeat exactly what I had done before, because it didn't work, I made some minor changes based on some of the comments I read here.
Currently, I have been unable to install Drupal and keep getting the aforementioned error. I will not attempt to install it again, until I get some ideas on what it is that could be wrong. I would appreciate any help I could get, as I am pretty frustrated right now.
Any ideas?
Misconfiguration
That error message is generated by the webserver, not by Drupal. Sounds like a misconfiguration of either your webserver, or of the permissions of your Drupal directory.
CHMOD what?
The Drupal files are in my doc root directory, public_html, as the install steps directed. I changed the permission of index.php and then that directory. I tried both 755 and 777 and got the same error.
I'd try Google'ng for this er
I'd try Google'ng for this error because it sounds like it isn't Drupal related/specific.
If you had an IIS server I wo
If you had an IIS server I would suspect that index.php was not set as the default document to load and your Apache server was configured for index.html instead.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
I solve this 403 error by adding a + to a line in .htaccess
I have the same error each time I do a Drupal install, but it is solved immediately by doing the following edit in your .htaccess file in the folder where you installed Drupal:
Change the line:
Options FollowSymLinks
to this:
Options +FollowSymLinks
Yes, that's right, just add a plus sign. It seems some server configurations need the + sign to understand the instruction clearly (the line before has a - sign: "Options -Indexes").
This 403 error upon installation seems to pop up frequently, yet it can be solved so easily. I can imagine it scares away many candidate Drupal users if your first experience is seeing an inexplicable error message and you can't get the thing going.
Why not remove a hurdle to Drupal takeup and change the standard Drupal installation .htaccess to include the + sign? Or at least add the solution to the handbook (I checked, I can't edit the handbook, otherwise I would do it).
Just my 2 cents.
PS. I got this tip from this page: http://drupal.org/node/8832
Updated .htaccess file
I just changed this in CVS HEAD so it will be changed in Drupal 4.5.0's
.htaccess
file. I hope that helps. Thanks.One less hurdle
Thanks Dries for zapping away this takeup hurdle. I must confess I just about gave up on Drupal after encountering this stubborn 403 error.
Perfect Solution
Thanks a bunch for this solution! I'm glad to find out it wasn't a server error for me, as some suggested it might be. I'm also glad a search for the solution yielded results for you. It didn't for me. Hence the need for proper keywords, I suppose. Anyway, all is up and running for me. Thanks again!
header and output sent...
1) downloaded http://drupal.org/drupal/drupal-4.5.0-rc.tgz yesterday morning
2) unpacked and modified includes/conf.php with user, pass, db and url
3) imported sql via phpmyadmin on remote site
4) uploaded online on http://www.mrshark.it/drupal/
5) create first login
6) login with temporary pass given by drupal
7) edit login to change pass, save account
8) follows the output...
warning: file_exists() [function.file-exists]: Unable to access in /home/web/www.mrshark.it/website/drupal/includes/file.inc on line 145.
warning: Cannot modify header information - headers already sent by (output started at /home/web/www.mrshark.it/website/drupal/includes/common.inc:406) in /home/web/www.mrshark.it/website/drupal/includes/common.inc on line 217.
Safe_mode
Is PHP's
safe_mode
enabled?yes...
phpinfo at: http://www.mrshark.it/p.php
yes, it's active, as you can see, but in the install requirements there's nothing about safe mode (file INSTALL). A way to solve?
One more thing to check
When I edit a PHP file on my site directly, the editor will add an extra line at the bottom of the file. (For instance, the editor that you get with CPanel always does this.) So instead of the last thing in your file being a PHP closing tag like this
the last thing in your file is a closing tag followed by a blank line like this
In fact, CPanel will add another blank line each time you edit the file and then save it back out, so you may end up with several blank lines at the bottom.
The problem is, PHP only interprets the stuff inside the tags. Anything outside the tags is delivered literally, so when it reads that file, it sends one or more blank lines to your webserver, which makes the webserver think that output has already started and that you can't modify the header anymore.
Try going back to your conf.php that you modified and make sure there are no blank lines after the closing tag.
nop...
there was a blank line, you're right, but even after deleting it, the error persists...
Can I upgrade from 4.5RC to 4.5 final in future?
[ I know this is a newbie question but please don't crucify me for that ;-) ]
If I use 4.5RC, will I be able to upgrade to 4.5 final cleanly?
Thanks,
Swaroop
www.g2swaroop.net
Oops, it's already mentioned in the article
sorry for not noticing that before!
Cache Problems
Since upgrading I've seen a lot of errors such as the following in my log. I've temporarily disabled caching to eliminate it:
user error: Duplicate entry 'http://www.macmegasite.com/node/1594' for key 1 query: INSERT INTO cache (cid, data, created, expire, headers) VALUES ('http://www.macmegasite.com/node/1594', '�\0\0\0\0\0\0��t���;�rd�\')H��%�� in /home/.jambalaya/macmega/macmegasite.com/includes/database.mysql.inc on line 125.
--
Mike Cohen, http://www.mcdevzone.com/