• Is anyone else here hosted with Media Temple and having problems with plugins that store file paths based on the ABSPATH constant?

    They’ve been doing some maintenance recently, and then I heard from someone I host that WP-DBManager was giving its big red “Your backup folder MIGHT be visible to the public” error. This error is supposed to alert you to the fact that the necessary .htaccess file isn’t in the backup folder to protect it. However, I do have the .htaccess file in place; the problem is actually that the plugin is suddenly looking for the file in the wrong place.

    As far as I can tell, some plugins (notably, so far, WP-DBManager and Smart Archives Reloaded) store file paths based on ABSPATH, which in turn is based on __FILE__. Media Temple give the absolute path for their Grid Server as something along the lines of /home/xxxx/domains/.... Most PHP environment variables return this value, but – presumably as it bypasses any mappings – __FILE__ returns some underlying value like /nfs/cxx/hxx/mnt/xxx/domains/... (I’m replacing all numerals with x’s.)

    This value that __FILE__ returns suddenly changed the other day. This meant that the current value and that stored by various plugins in the DB options table no longer match. So, Smart Archives Reloaded can’t read its cache file and return errors, and – most worryingly – WP-DBManagerManager can no longer find its backup folder, and my scheduled DB backups no longer work.

    I’m still corresponding with MT about this. Their only response so far is that the /nfs/... path is “subject to change at any time”, and that I should use the other one, which is fixed. Well, for a start, this has never happened to my knowledge in my 4+ years of hosting with MT. And of course, how popular WP plugins and the WP core behave isn’t really my choice.

    Where does the fault lie? MT seem to be much less knowledgeable about WP than I assumed they were. Surely if the value of __FILE__ changes all the time, they would know the impacts this might have and warn WP customers? On the other hand, what’s the difference between the path __FILE__ returns and those built on PHP environment vars? If the latter returns values that hosts can fix, while the former might change, should plugin authors be storing values crucial to their functioning, based on __FILE__, in the DB?

    My guess is that the option of scouring through all the plugins I use and seeing which rely on __FILE__ in this way, and finding alternatives that don’t, would be impractical. As would wrangling with phpMyAdmin to manually change stored paths every time MT’s server paths suddenly change.

    At the moment I’m seriously looking at other hosts. Anyone else having the MT’s issue, or have an opinion on the situation?

Viewing 2 replies - 1 through 2 (of 2 total)
  • Smart Archives Reloaded doesn’t store any path in the DB. It uses wp_upload_dir() to determine the path for it’s cache.

    Thread Starter Steve Taylor

    (@gyrus)

    You’re right, sorry. I’m not sure why I was suddenly getting errors from SAR at the same time as the above issue, telling me it couldn’t find the cache file. It seems to be working OK now I’ve replaced the old paths in the DB anyway. It’s never happened before, but I’ll have to put it down to wild coincidence & mystery!

    The actual issue remains. MT say the path won’t change often, but that’s not ideal. Lester Chan says he has no idea why MT need to change it. Other common plugins I rely on, like cforms, definitely DO store ABSPATH-based values in the DB.

    I’m left wondering why MT need to change the paths, and why WP bases its ABSPATH on __FILE__, which picks up MT’s path changes, and not a PHP environment var, which picks up their stable mask for the paths. Ah well.

Viewing 2 replies - 1 through 2 (of 2 total)
  • The topic ‘Media Temple server path changing’ is closed to new replies.