Grasping at straws now – should WPMU & BP be in same DB or different?
-
I’ve tried 3 different installs of WPMU 2.8.4a and BP 1.1.2 (sub-domain set up in site root install) on three different hosting services on three different continents (UK, US, & Singapore) all with MySQL 5.x, PHP 5.x, and 128 – 256 MB RAM available.
For each install, fresh downloads of WPMU & BP were made, therefore reducing the possibility of corrupted code being transferred from server to server, unless the code in the WPMU/BP servers that deliver to SE Asia is already corrupted?
The only plugins active at any time were (in WPMU) Akismet and Default Blog Settings … and BuddyPress of course. No BuddyPress plugins were activated at any time.
On all three servers, I got exactly the same problem with the Groups avatar upload / cropping tool that I reported as a bug in trac (which someone appears to have deleted) and which I’ve tried to resolve for over a week now here in the BP forums, and in the WPMU forums. THe only useful pointer I’ve discovered came in fact from the osCommerce forums and related to the javascript used to resize images in the avatar cropper – even though it was referring to an entirely different sitescript and tool, although the usage was similar.
So here we go again, and for the lord knows how manyth time, let me describe the behaviour –
1 – first time access to the Creat Groups sub-routine (i.e. first ever group created on a site with new install) on the Group avatar page, the Back, Upload, Skip buttons appear.
2 – attempting to upload an avatar (all attempts – first time, second time, exit and return and try again, go to admin and edit group avatar etc) the cropper tool fails to grab the image and displays only a black 88px x 16px background “bar” in the avatar viewer.
3 – At step 2 above, after the very first upload attempt for the site, the Back & Skip buttons on the avatar upload page disappear (this means the avatar cannot be skipped and jump to send invites, nor go back to try and reload the page fresh for another attempt within the create group loop.)
After each attempt that reaches step 2, there is a report from BP that the image failed to upload, but the image is in the correct directory/folder on the server, with the correct filename etc and can be viewed using the cpanel image viewer from file manager.
There is NO server log error spawned from the avatar uploader/cropper – ergo – it is the javascript that is incomplete, or pointing to the incorrect file location, or cannot follow the complete path to the file (exactly who decided to place a period in the folder name blogs.dir – and why – I’m sure that’s at least a piece of the problem). It is possible to cause the uploader/cropper to spawn a server error log by not “browsing” to acquire an image, then clicking save – the “no image selected, unable to save” type message does record to the server error log, proving that bit of the code to server interface is working.
Let me clarify step 3 – the Back and Skip buttons only ever appear ONE time, which is the very first time the Group Avatar page is accessed on any one site install. After that, they never appear again – poof! gone! disappeared into the ether! – their code does not even appear in page source (using mouse – right click – view source) nor does it reveal in code or css when viewing with firebug.
It is as if the Back and Skip buttons have been programmed as a one-time only “display then destroy” piece of code – a bit like toilet tissue?
So, the “grasping at straws” question –
The only thing I have not yet tried is to put WPMU & BP into their own databases – does BP require that it is installed into a different database to WPMU? All the documentation (and default install) puts it in the WPMU database with unique “bp_” prefixes.
—
Everything above tested and displayed in Firefox 3.5.3 and IE 6.5 on WinXP & Win2000 workstations, and on Win2000 Server box (in both server and workstation mode) with hosting on Linux/CentOS shared hosting services at THREE different hosting companies on three different continents …. although I haven’t tried a southern hemisphere hosting company yet – maybe the upside down “down under” positioning will give a different result? LOL
The issue / bugs above are still not resolved
– I did report them in the bug tracker, but someone deleted the report.
– I have reported them several times in BP forums and DJPaul keeps telling me to start my own thread, OK – here it is
– Looking through the BP forums, this issue (avatar cropper) is going the same way as the basic “WP flash uploader failing to complete crunching and upload” bug over on WP.org – and that has hundreds if not 1000’s of threads open for it (since WP 2.5.x).
Help appreciated
Gaz
-
Your avatar problem is probably because of the file itself. What kinda file do you upload? If it’s some kinda rare file like .raw then it’s obvious it wouldn’t work. If you could, also place the specs of the image, like if it’s cmyk/rgb, how many bits, the size of the image and wether its transparent or not.
Right now Buddypress has to be in the same database as wpmu, I heard they might make it possible to put into another database later in development.
And while your at it, could you make me some coffee too? Haven’t slept for 22 hours..
The reason my avatar appears in WPMU is because it’s picking up my Gravatar in those places.
If WPMU is also having an issue with uploads, then I reckon this is probably not a BuddyPress issue (yet.)
Sounds like you need to activate BuddyPress to me.
Hi Jeff – key comment in this reply is the last line
So, if your source image is smaller than 150 on at least one of its dimensions, you could have issues with creating the large avatar. If it is smaller than 50 on at least one of its dimensions, you could have issues with creating the small and large avatar
So what happened to css basics?
e.g.
maximum-width; 150px
note the use of maximum-width as opposed to width – or is that not available in javascript ? (genuine query as I don’t know js coding at all) – also, note the dimensions I gave in reply to Xevo way back up the thread.
it may be that your server is running too old of a version of the GD image library
possible, though highly unlikely with this particular host – I’ll check with them though.
never use the auto-upgrade feature when upgrading WPMU or BuddyPress. It is simple and quick enough to manually upgrade them and it gives you more control and assurance that it is done right.
Side topic response, but – I’m 2,000 miles from the closest of my servers (Singapore) and 8,000 from the main one where the install is running a deadline, and 12,000 from the US hosts that I also use heavily. It is NEVER quick to manually download the package, extract it and upload it from here – assuming the locals can keep the electric on for more than an hour at a time, and the internet connected for two consecutive minutes – that’s why the auto-upgrader was such a godsend when it arrived in 2.5 Having said that, I’ve noticed some very consistent differences on it with UK and US hosts – both the auto upgrader and the plugins/theme direct download to site and upgrades, work flawlessly on US hosts and never ask for FTP login. On UK hosts, they all always ask for FTP user login from wp-admin, and greater than 50% of the time they fail to complete all expected on-screen steps. I’ve also noticed that UK hosts tend to override the timeout preventions built into WP, which US hosts do not do. ….. don’t get me started on the pricing differences either – LOL
Are you on a shared or dedicated server? Talk with your hosting firm to see if there is some javascript-based application that the hosting firm has running on your server that could be interfering with the basic JS operations in WPMU
It’s a shared server, but a reseller account – half way step between shared and VPS as in limited main accounts per server but with dedicated RAM per reseller account and so on.
The background js / mootools question is a good one that I’ll fire at them.
On the UK install, I’ve tried every possible config right down to the barest of bones – even to the point of deleting (not just deactivating) all plugins and themes and dropping all tables created by any plugins – still problems persisted.
It got to the point a couple of hours ago that I finally had enough and made liberal use of the Ctrl+A and Del keys
Pffzzzzzt – zap – gone – empty domain space. I’ll be nuking the database in a minute or two as well, then uploading from scratch and starting again in the morning (1:00am+ here now) after letting the dust in my head settle after spending the whole weekend scouring the WPMU and BP forums trying to resolve this.
I’ll also be starting with a WPMU install that has no periods in its directory and folder names – i.e. NO ” blogs.dir ” style of names – I am convinced that is a major source of some problems related to images, just as I am convinced that the user blog folder tree goes way to deep for Google search bots to follow it all the way to the bottom – and that’s gonna hurt SEO.
As I said up a bit, I’ve nuked the install (and the test installs) and will make a fresh start tomorrow … to mis-quote a famous movie line –
“I love the sight of deletion in the evenings” ~ Major Lee Pistoff, in aPressolypse Now
LOL
Gaz
- The topic ‘Grasping at straws now – should WPMU & BP be in same DB or different?’ is closed to new replies.
