mpcee123

Nate,

I added the following CSS to my theme, which got rid of the phantom window resizing on pages:

#content { overflow: hidden; }

Perhaps that CSS can help someone else out as well (a pretty simple fix).

I’m closing the thread. Thanks again!

Mike

Wow–brilliant detail! Thanks much!

As it seems, my best bet is to figure out the mysterious “extra width” and correct it on my end, I guess. (I should probably do that anyway!)

Thanks so much for your help, Nate (assuming that’s your name ?? )

Mike

Quick update on #1:

My home page and other “pages” show the extra space, but “posts” do not. As I stated before, I will try to resolve this issue.

As for #2, that’s all you ??

Mike

Thanks for checking on things.

I’m still experiencing the problem in the same way, unfortunately.

Two things:

1.) I have no idea what is causing my page to show extra space on the right hand side. I will look into this issue (never noticed it before).

2.) Does the MailChimp plugin/widget default to moving the window all the way to the right? If so, why?

Again, thanks for your help. Much appreciated!

Mike

Sure. https://www.kindredroad.com. Right sidebar, second widget from the top.

You’ll probably need to actually sign up for the mailing list to test things, but if you don’t confirm the subscription, you should remain off the list. But I suppose I don’t need to tell you that!

Thanks!

Mike

Chris,

Thanks for your response!

Manual setup: Wow, what a hassle. Seems as though it would be a lot easier to just copy the scripts I want to exclude from getting minified, rather than find all of those I want to minify.

Good call on disabling the jQuery from SexyB….

I tried an alternate method as my solution. I’m using CloudFlare with its minify functionality disabled, since I use W3’s minify code (well, except for JavaScript, as we’ve seen here). I’m letting W3 handle minifying the HTML and CSS, and I turned on the CloudFlare’s JS minify functionality.

And guess what? Everything works fine. Perhaps CloudFlare’s JS minify algorithm isn’t in conflict with SexyB.

I’m going to roll with this solution for the time being.

Cheers!

Mike

Kurt,

I’ve been using the latest version of Google Chrome (18.0.1025.168). That’s the browser that hung (and continues to hang) with P3.

I just tried things in IE 9 (9.0.8112.16421) though, and everything worked fine.

Perhaps the plugin has a problem with the latest version of Chrome?

Good on you for your suggestion to use a different browser. Not sure why I never tried that myself…brain fart I guess. ??

Thanks!

Mike

Kurt,

Thanks for your response.

I should have been clearer: As soon as I hit the “complete” button, the window was rendered completely useless (i.e. not even possible to scroll), as if it had entered an infinite loop. I was prompted by the browser to kill the page since it was unresponsive, but I selected to wait (to no avail).

After scanning the plugins, the program hits an infinite “thinking” loop…and the loop just continues on and on.

Mike

@adiant,

Alright, perhaps this will be my process … for now. (Things always change!)

FYI: An interesting new development … IF I was planning on running a WordPress MU setup. https://markmaunder.com/2011/08/19/deploymint-a-staging-and-deployment-system-for-wordpress/

Thanks again for the help!

Mike

@adiant,

So then create a third XML file containing only the identified changes, and import only those changes back into Development. Then, perform the full database and file deploy to Production. Yes?

Mike

@adiant,

Not a bad idea–and certainly a way to spot changes. But visually comparing changes in text files is a bit tedious, no? Not to mention dangerous if I start doing “cut and pastes” by hand?

Mike

@adiant,

Right on–“test like crazy” should be the air we all breathe. ??

I appreciate all your insight–more than you know. It’s just nice to at least bank some ideas off of some other folks as I’m still new to the process.

I hope some others find this thread, as I know many have lingering questions on this issue that haven’t been resolved. Piecemealing together random, dated internet tutorials spanning the last 3 years can drive a man crazy after a while.

Cheers again for you help!

Mike

P.S. Anyone else with thoughts on all of this? PLEASE, don’t hesitate to jump in here!

So then ideally, the process would go something like this:

1.) Copy down all files (if not already present) and database contents to development environment from production, which is running in a subfolder of the root public directory. (All configuration changes, scripts, etc. necessary to make the production install work in the development environment will need to be run.)

2.) Make all necessary changes in the development environment.

3.) Freeze production.

4.) Export “All Content” from production.*

5.) Import “All Content” in development.*

6.) Upload everything from development to a second folder under the root public directory on production, making sure to make all necessary URL changes and such (as always).

7.) Change index.php in production to point to the newly uploaded content.

* My issue: Exporting “All Content” seems to be the only way to get everything all-at-once from production. However, if you changed the navigation, terms, etc. in the development environment, you would have a problem here. I think a mandatory manual edit of the XML file might have to be done.

I think we’re close here, but there has to be an “it” way to do this. WordPress has been around way too long to have the only solutions be custom scripts spread here-to-there around the world…

Mike

@adiant,

Wow, you’re quick on the reply! Cheers!

My responses to your responses:

1.) Excellent idea for no down-time. I will definitely be looking into this option. Love it.

2.) The “freezing” of production idea is a good idea if it’s feasible. However, I still don’t think it answers everything. What if you download your production data a week ago to your development environment and you needed an entire week to make your changes, many of which impacted the database used in the development environment. You’re not going to “freeze” production for the entire week that you worked, are you? And after having made so many changes to the development environment, you can’t just download a copy of the production database again. You have to merge things somehow. Is that what the XML export feature is intended to accomplish? Situations like this?

3.) I here ya on the wp-config.php and permalinks stuff. In creating my https://dev.mysite.com test site yesterday, I got a crash course in all that stuff. AND I had a chance to experience the “Search and Replace” plugin. Although, I would say that the script listed here is more complete: https://interconnectit.com/124/search-and-replace-for-wordpress-databases/.

4.) I know, I know: I could be safer with the test environments. Right now, my focus is more on just understanding how to USE test environments effectively with WordPress.

5. (second post) Cheers on the “updating WordPress” info. I’m aware of WordPress’s release naming structure and how the security updates come a bit later. Great points on upgrading though.

While I wouldn’t have understood much of anything early yesterday, things are making a lot more sense today. #2 is still our issue though, I believe.

Cheers again, adiant. Feel free to reply again!

Mike

P.S. I was reading this when your reply came through: https://wordpress.stackexchange.com/questions/2100/database-synchronization-between-dev-staging-and-production

I’m not the only one with these problems… (Comfort in numbers? Maybe…)