#6555 closed defect (bug) (invalid)
With multiple WP installs, calling functions from external directory always retrieves results from first blog
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Milestone: | Priority: | normal | |
| Severity: | major | Version: | 2.5 |
| Component: | General | Keywords: | has-patch |
| Focuses: | Cc: |
Description
This is hard to explain, but maybe the example will make sense:
With multiple WP installs, calling functions from external directory always retrieves results from first blog, even when specifically referencing other blog directories.
I have two seperate blog installs at mydomain.com/blog1 and mydomain.com/blog2. Note that mydomain.com is outside all the WP installs.
An external program that tries to pull the posts out of each blog, always gets the blog1 posts, even when it should be getting blog2 posts. Here's how to recreate:
Take the following code:
<?php
//Displays the title of the 3 most recent posts in the blog
require('./wp-blog-header.php');
query_posts('showposts=3');
if (have_posts()) : while (have_posts()) : the_post();
the_title();
?><br />
<?php endwhile; endif; ?>
Save it as BlogOnePosts.php and upload it to mydomain.com/blog1 directory.
Now save the same code again as BlogTwoPosts.php and upload it to mydomain.com/blog2 directory.
Go to mydomain.com/blog1/BlogOnePosts.php and you should see this:
blog1 post another post first post
Now goto mydomain.com/blog2/BlogTwoPosts.php and you will see this:
blog2 mypost second blog post first but not reallt post
As you can see each blog correctly displays it's own posts...
Now take this code:
Blog 1<br />
<?php include('/home/public_html/blog1/BlogOnePosts.php'); ?>
<br /><br />
Blog 2<br />
<?php include('/home/public_html/blog2/BlogTwoPosts.php'); ?>
Save it as BlogPosts.php and upload it to your mydomain.com directory (outside both wordpress installs).
Now goto mydomain.com/BlogPosts.php
You will probably get an error message like this:
WARNING: require(./wp-blog-header.php) [function.require]: failed to open stream: No such file or directory in /home/public_html/blog2/BlogTwoPosts.php on line 3 WARNING: require(./wp-blog-header.php) [function.require]: failed to open stream: No such file or directory in /home/public_html/blog2/BlogTwoPosts.php on line 3 FATAL ERROR: require() [function.require]: Failed opening required './wp-blog-header.php' (include_path='.:/usr/lib/php:/usr/local/lib/php') in /home/public_html/blog2/BlogTwoPosts.php on line 3
To fix this error message...
In the BlogOnePosts.php change this line:
require('./wp-blog-header.php');
to this line:
require('/home/public_html/blog1/wp-blog-header.php');
Now in the BlogTwoPosts.php change this line:
require('./wp-blog-header.php');
to this line:
require('/home/public_html/blog2/wp-blog-header.php');
Now got back to mydomain.com/BlogPosts.php, and you see that Blog 1 shows the three most recent posts correctly, but Blog 2 shows the three most recent posts from Blog 1 as well instead of it's own posts, like this:
Blog 1 blog1 post another post first post Blog 2 blog1 post another post first post
As you can see the call in BlogPosts.php for Blog 2 is specifically referencing blog2/BlogTwoPosts.php and the require statement within BlogTwoPosts.php is specifically referencing blog2/wp-blog-header.php but it is returning results from Blog 1 !!!
Change History (7)
#1
@
18 years ago
- Milestone 2.5.1 deleted
- Resolution set to invalid
- Status changed from new to closed
#2
@
18 years ago
It used to work fine in v2.3 !!! Why would it no longer work in 2.5?
Is there a way to clear the global variables?
Thanks
#3
@
18 years ago
There are much cleaner methods of doing what you are attempting to do. Like westi, I'm surprised it ever worked for you (that second include should give you "function already defined" errors). Why don't you use something to merge the top three entries from the RSS feed? Or do the very dangerous thing of directly accessing both databases and running a custom query to get the data you want.
#4
@
18 years ago
Okay, thanks for input.
Have been doing it that way for a while per suggestions found on the support forum, which is really a bunch of dangerous people (like me) armed with just enough knowledge to figure out how to do something the wrong way and then pass it on to others!!!
This ticket was mentioned in PR #6594 on WordPress/wordpress-develop by @Bernhard Reiter.
18 months ago
#5
- Keywords has-patch added
This is a variation (no pun intended) of @tjcafferkey's #6555. It's the same commits, but cut off after 52d6b3d926ed8fc2af6eba4c79a4fecd6aa32767 -- i.e. with no changes to the WP_Block_Type and WP_Block_Type_Registry classes. Instead, the canonical block name is extracted early on during instantiation of the WP_Block instance, and used to interact with those other classes.
This seems to be working for me:
@Bernhard Reiter commented on PR #6594:
18 months ago
#6
As @tjcafferkey pointed out to me in DM, the fact that we're getting the wp-social-link-wordpress class name is due to the Social Link block (rather than a more generic mechanism):
$wrapper_attributes = get_block_wrapper_attributes(
array(
'class' => 'wp-social-link wp-social-link-' . $service . block_core_social_link_get_color_classes( $block->context ),
'style' => block_core_social_link_get_color_styles( $block->context ),
)
);
So we can't rely on that for other blocks. Instead, we _will_ have to generate the class name for the block variation.
@Bernhard Reiter commented on PR #6594:
18 months ago
#7
I've just pushed https://github.com/WordPress/wordpress-develop/pull/6594/commits/d7735f8b2bc67bce277f1288bbf7856959cc9851 which is one attempt at solving the problem. It infers the block variation name based on the strategy described in https://github.com/WordPress/gutenberg/issues/43743#issuecomment-2122361093.
This seems to work alright, but _only for blocks whose variations are registered on the server side_. Examples are the Template Part or Navigation Link blocks. (The Social Link block sadly isn't.)
---
You are doing something very dodgy and I'm supprise it even works this much.
When requiring the second WordPress install's wp-blog-header.php in you are bringing in a load of the same files and settings.
All the global variables will be already setup when the second one is included.