Ticket #3349 (closed enhancement: fixed)

Opened 2 years ago

Last modified 1 year ago

wp-config pickup consistency fixes

Reported by: RuddO Assigned to: rob1n
Priority: normal Milestone: 2.3
Component: Optimization Version: 2.1
Severity: normal Keywords: 2nd-opinion
Cc:

Description

What this patch does:

* calls WP's wp-config.php consistently throughout WP (before it was a mixture of ../'s and dirname(FILE)'s) * lets anyone use a WordPress tree composed out of symlinks without issues (perfect for those who host hundreds of WPs in a single server for hundreds of customers, and who by any reasons won't use WP-MU)

These fixes work OK on my setup, and should work OK on others' setups. Just tested creating a new blog and it's all good.

Attachments

2.0.5-phantom-wp-config-consistency.diff (5.3 kB) - added by RuddO on 11/09/06 21:14:35.

Change History

11/09/06 21:14:35 changed by RuddO

  • attachment 2.0.5-phantom-wp-config-consistency.diff added.

11/09/06 21:15:10 changed by RuddO

  • type changed from defect to enhancement.

11/10/06 04:18:57 changed by markjaquith

  • keywords set to 2nd-opinion.
  • owner changed from anonymous to markjaquith.
  • status changed from new to assigned.

At first glance, this looks fine.

11/10/06 06:01:40 changed by RuddO

Thanks, Mark. I did work on other plugins and submitted them to their respective authors. The last author I will contact is the wonderful FireStats? plugin's, where my fixes initially didn't work because the "offending file" was already being included via a dirname(FILE), thus I had to use getcwd(). It worked with getcwd() though.

11/10/06 19:43:27 changed by foolswisdom

+1 on consistency -1 on ./ it is obtuse, leads me to do a double take to ensure it is not ../

11/10/06 20:42:37 changed by masquerade

+-0 for consistency, the whole codebase is inconsistent, and I don't care any more. -1 for anything that requires any plugin under any condition to have to use getcwd. Its not reliable.

11/14/06 06:15:15 changed by RuddO

foolswisdom: I based the ./ on the fact that some WP files already used it. it seems to work fine, whereas under some (admittedly not common, but possible) conditions, the famed dirname(FILE) fails.

this patch does not introduce any usage of getcwd(). Only my FireStats? patch (mailed to the author) did. As you say, getcwd() is not reliable, but it was the only way I could get FireStats? to work, and the getcwd() mod went only into FireStats?.

11/14/06 06:19:35 changed by masquerade

The fact that we are breaking plugins like this one and maybe others that we don't know about is unacceptable. If getcwd is the only way something will work with this patch applied, thenI don't think it should be applied.

11/14/06 12:13:06 changed by markjaquith

I think the FireStats? issue was a result of him using Symlinks... not this change. Obviously I don't want anything going in that breaks plugins on normal installs. But if this leaves normal installs alone but allows more creative setups, I don't mind it. RuddO, can you clear up the reason for having to use getcwd() ? Because of symlinks or this patch?

11/14/06 20:52:09 changed by JeremyVisser

Nothing to do with this particular issue, but the K2 Sidebar Modules broke for me as well, due to the fact that I symlinked the K2 theme directory from my blog to my Dad's blog and was wondering why the "K2 Sidebar Modules" option showed up on my blog, but not Dad's. A long time later, I realised it was because of the dreaded __FILE__ which resolved the symlinks and broke the path names.

11/21/06 20:45:07 changed by omry

RuddO, I never got your patch, please re-send.

11/21/06 20:47:27 changed by omry

or better yet, open a ticket for it at firestats.cc, and attach the patch there.

12/03/06 09:28:54 changed by markjaquith

  • version changed from 2.0.5 to 2.1.
  • milestone changed from 2.1 to 2.2.

We can play with this after 2.1

04/11/07 03:32:32 changed by rob1n

  • milestone changed from 2.2 to 2.3.

04/11/07 03:32:36 changed by rob1n

  • owner changed from markjaquith to rob1n.
  • status changed from assigned to new.

08/03/07 00:45:06 changed by markjaquith

  • status changed from new to closed.
  • resolution set to fixed.

(In [5843]) Consistently include wp-config.php. fixes #3349