ohnoezmahblog

Thanks for the response, it’s just custom CSS. Like for example I have a <div> set to 75% width, but when the screen size gets too narrow I’ll want it to resize to 100% width.

I can see that the Astra theme is doing stuff to make the site responsive e.g. with the header, is there a best practice or documentation anywhere of what Astra is doing so that I don’t make any conflicting changes?

For starters, what are the pixel width breakpoints where Astra does stuff, and what does it do at those breakpoints?

Update: using aria-haspopup="true" works quite nicely for IE10+, but from my fiddling it seems that it must be doing something else for Chrome…

Thanks for this.

I think when you properly install WordPress to a subdirectory, it does the redirection without using a RewriteRule like your example in the .htaccess file, though. I have several other sites installed in subdirectories on other URLS, and their .htaccess files are as I posted, without the subdirectory redirect. Thoughts?

OKAY: so, hardcoding the siteURL and Home by adding these lines to the wp-config.php file:
`define(‘WP_HOME’,’https://www.example.com&#8217;);
define(‘WP_SITEURL’,’https://www.example.com/subdirectory&#8217;);’

SOLVES the admin redirect, and now hey presto the site loads correctly.

I’m out of time to work on this today, but my suspicion is that the plugin WP-Supercache, which also writes RedirectRules to the .htaccess file, is not picking up the cues and is interfering with whatever WordPress is doing.

I’ll post back whatever I figure out. But it’s nice to know I can fix the admin redirect loop by adding those lines to the wp-config.php file.

Looking at another site I have set up in a similar way, here’s how I think this should work:

In the database, all the stored urls should be of the form:
www.example.com/subdirectory/ EXCEPT the siteurl, which should be without the subdirectory.

The .htaccess file should look like this:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

The root site index.php should have:
require( dirname( __FILE__ ) . '/subdirectory/wp-blog-header.php' );

While the subdirectory index.php should have:
require( dirname( __FILE__ ) . '/wp-blog-header.php' );

At least, that’s how my other site is set up, and it works. But not here.

Thanks.

I adapted that SQL command from the guide here, if it helps someone else (also the best guide I’ve found on how to move WordPress).

The other tool that is helpful is Broken Link Checker, because of the vagaries of file naming there will be some links that don’t restore, this will tell you where they are.

Really, it seems like WP could have some more smarts in this respect.

Okay, I figured out a work-around:

I uploaded all the files again via the Media Uploader, and that put them in a folder like:
https://www.yourdomain.com/wp/wp-content/uploads/2013/03/

So now WordPress knows about the media, it just has the wrong link.

Then, I went into the phpmyadmin backend, and used SQL commands like:
UPDATE wp_posts SET post_content = replace(post_content, 'https://www.yourdomain.com/wp/wp-content/uploads/2012/','https://www.yourdomain.com/wp/wp-content/uploads/2013/')

Which would update all paths that were in the 2012 folder to the same month in the 2013 folder. Once I had done all the years, I did months:
UPDATE wp_posts SET post_content = replace(post_content, 'https://www.yourdomain.com/wp/wp-content/uploads/2013/01/','https://www.yourdomain.com/wp/wp-content/uploads/2013/03/')
Running that command for every month. That restored the vast majority of my links.

Drawbacks:
1. It doesn’t restore Featured Images.
2. All of the media is listed as Unattached.

Also, make sure you backup your database before attempting this. It’s really easy to hit the wrong key and break your database irrevocably.

Hope it helps someone.

Just wanted to chime in – I had this problem, and it turned out that the capitalization was different on the parent theme folder name from what I had in the child style.css

So capitalization apparently matters, check all that stuff first.

I am also interested in how this works! Did you ever set up screencast or tutorial?

Thanks for your care and time, it’s a great idea.

Thanks for the pointers. I renamed the URL parameter to post_to_fetch, which didn’t have any effect that I could see, but I agree that it’s a better practice.

Regarding #3, I believe the output is being wrapped in <p> tags from the php file, is that what you mean? The <p> tags are making it into the html source.

I feel like there’s some kind of file I need to include or something, that is included in the standard php files loaded by WordPress. That post query code is straight out of the codex, I don’t think it’s the code per se.

Since I’m able to pass information through the php file and back out to the html I feel like it’s not an AJAX problem.