Make WordPress Core

Opened 18 years ago

Closed 18 years ago

Last modified 18 months ago

#6555 closed defect (bug) (invalid)

With multiple WP installs, calling functions from external directory always retrieves results from first blog

Reported by: jsherk's profile jsherk 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 @westi
18 years ago

  • Milestone 2.5.1 deleted
  • Resolution set to invalid
  • Status changed from new to closed

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.

#2 @jsherk
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 @mtekk
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 @jsherk
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:

https://github.com/WordPress/wordpress-develop/assets/96308/097474cd-c7bb-46ea-aff4-b38b2252925a

@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.)

https://github.com/WordPress/wordpress-develop/assets/96308/d49678b8-2a94-4a2c-95aa-424fc742b4c0

---

https://github.com/WordPress/wordpress-develop/assets/96308/11b0a1e4-16ee-4b28-be25-f535aba262a7

Note: See TracTickets for help on using tickets.