Adjusting WP Site Adress (URL) lead into Codekit Server Troubles

[rpkoller]

I am using MAMP 2.2, the non pro version. within CodeKits external server settings: external server required is set to on and the adress is set to http://localhost:8888 with a preview subpath of test/ . So far everything worked properly. But i had only one minor issue in the theme i play around with at the moment. If i clicked on the logo which redirects back to the front-page Safari and Chrome loaded forever. the href of the logo contains: <?php bloginfo( 'siteurl' ) ?>

If i get to the back wp backend settings-genereal site adress url shows http://olymp.local:5757/test without a slash at the end. when i tried to add a slash problems started. after entering http://olymp.local:5757/test/ and save changes wordpress showed http://olymp.local:5757/test again.

now if i click a link in the menu e.g. news the url changes after a second from http://olymp.local:5757/test/news/ into http://localhost:5757/test/news/ which leads into a safari load error due to too many redirects. :/

osx 10.8.5 / wp 3.8.1 / safari 6.1.1

[rpkoller]

on the front page no images are displayed anymore. :/ if i get into the backend the assigend images are shown on the front page non is shown anymore too additionally. :/

shall i pack the whole wp site and send you again? the version i've sent you once a few weeks back is a bit outdated meanwhile.

[rpkoller]

uh false alarm at least regarding the not displayed images. that 's due to my last comment from issue #214 . the js path has changed and i have forgot to update it. but the adress issues from my first post in this issue still persists.

[rpkoller]

and is it possible that codekit rewrites the wordpress adress (url) and site adress (url) in wordpress settings - general? i really can't remember that i have ever entered olymp.local:5757 there? and the probleme is i am unable to use wordpress in codekit 1 as long as i am having those issues in codekit 2. using codekit 1 instead shows just a few errors in the console, all unable to load urls pointing to port 5757 and olymp.local. :/

[bdkjones]

Ralf, you have totally screwed up your Wordpress settings. This is not a CodeKit issue.

Your SiteURL and SiteRoot properties in Wordpress's settings database should NEVER point to CodeKit's server address. Ever. Those properties need to be configured for your external server; set them as if CodeKit did not even exist.

CodeKit does not modify those settings at any point.

[rpkoller]

@bdkjones that is what puzzled me. and honestly i've never touched those settings?! the only thing i've tried was to add a trailing slash like i've described in my initial post in this thread. :/ but i've never entered or changed anything in the wordpress and site adress. i've entered my adresses in those two fields on initial install and then never touched it again. also checked backups from about 2 weeks ago, there the sql dump shows still localhost:8888 in wp_options as adress.

to fix things it would be the easiest to switch from olymp.local:5757 to localhost:8888 in both the wordpress adress and the site adress? and quit codekit before the settings are changed?

[rpkoller]

hmmmm i've tried to change the wordpress and site adress from olymp.local:5757 to localhost:8888 . but when i hit save changes it reverts back to olymp.local? odd :s

[rpkoller]

i've connected to my wp db via sequel pro now. i've checked the wp_options table and there both site_url and home have localhost:8888 as url and if i search for olymp contained in an option_value i get zero results. olymp is only shown in the backend not in the db. but still unable to change it there. thats really odd :/

[rpkoller]

ok back to normal. and i think codekit 2 has had its share in the scenario. as i described while codekit2 was running i was unable to change siteurl and home in the backend from olymp.local:5757 to localhost:8888. but in the db the adresses still were localhost:8888 ( i could send you a quick screencap vid). even if i ended codekit2 and changed to codekit 1 hasn't helped. also ending mamp, clearing browser caches, updating permalinks - nothing helped. all correct in the db but not in the backend. i dont know what changed but a few minutes back when i've ended codekit2 once again suddenly it worked again in safari. i was finally able to get into wordpress again via localhost:8888 in the browser- before it loaded forever. the siteurl and home have localhost:8888 instead of olymp.local:5757 in the backend settings again (havent changed anything manually). works fine with codekit1 again. but am a bit of afraid of firing up codekit 2 again :/

[bdkjones]

CodeKit had nothing to do with your wordpress settings. Seriously. I wrote the app; I know every line of code in it. It's not possible for the app to change those database settings.

Sent from my iPhone

On Feb 10, 2014, at 3:31 PM, Ralf Koller notifications@github.com wrote:

ok back to normal. and i think codekit 2 has had its share in the scenario. as i described while codekit2 was running i was unable to change siteurl and home in the backend from olymp.local:5757 to localhost:8888. but in the db the adresses still were localhost:8888 ( i could send you a quick screencap vid). even if i ended codekit2 and changed to codekit 1 hasn't helped. also ending mamp, clearing browser caches, updating permalinks - nothing helped. all correct in the db but not in the backend. i dont know what changed but a few minutes back when i've ended codekit2 once again suddenly it worked again in safari. i was finally able to get into wordpress again via localhost:8888 in the browser- before it loaded forever. the siteurl and home have localhost:8888 instead of olymp.local:5757 in the backend settings again (havent changed anything manually). works fine with codekit1 again. but am a bit of afraid of firing up codekit 2 again :/

— Reply to this email directly or view it on GitHub.

[rpkoller]

i seriously have no doubt about that. i was just reporting what i saw. and seriously it was odd. and i don't wanna say codekit was sole cause of that issue. but maybe one part in a chain of events. the only thing i can add is after fiddling around and trying to get things going again (deleted browser caches, ended and started mamp, tried to change siteurl and home in the backend manually, tried codekit1 and localhost) - nothing helped. then all of a sudden when i was trying with codekit2 again. when i've ended codekit2 and started codekit1 everything worked again. and in the backend all of a sudden siteurl and home show localhost:8888 again as url. again matching the localhost:8888 from the db ( never changed there). odd overall. maybe somehow mamp cache related??? real odd.

[rpkoller]

and i am running on beta 16 again now, it is behaving normal again.

[adamnorwood]

I can confirm this issue, and related troubles if using the auto refresh server when working with WordPress — it's a significant deal-breaker for my team's ability to use the new CodeKit 2, unless we're missing a step somewhere in the configuration.

Test system: CodeKit 2.0.1 build 16844 on OS X 10.9.2, running Apache 2.2.26 as the local development server, WordPress 3.8.1.

Steps to reproduce:

• Install and configure a basic WordPress instance in the root of our test environment. I'll call this environment whatever.dev and can confirm that everything's fine when browsing to http://whatever.dev/
• Add one of the WordPress theme directories as a new CodeKit project
• Enable "External Server Required" for this project, and set "External Server Address" to http://whatever.dev/
• CodeKit's internal server is now running and available at http://[machine name].local:5757 Browsing to that URL presents a seemingly a-ok WordPress site.
• Open the WordPress dashboard, and navigate to Settings > General.
• Presumably because CodeKit is proxy rewriting all instances of 'whatever.dev' to '[machine name].local:5757' before sending the HTML to the client, the "WordPress Address" and "Site Address" text input fields are now populated by "http://[machine name].local:5757" instead of the expected "http://whatever.dev", as seen in the screenshots @rpkoller posted over on #311

This automatic rewriting (assuming that's what's going on?) presents at least two major problems for WordPress development:

1. Nothing is broken immediately after following the above steps, but if someone were to hit "Save Changes" on that General Settings page, WordPress would store the CodeKit internal server address in the database as the siteurl and home values in the wp_options database table. This would then kill WordPress's ability to respond correctly at http://whatever.dev/
2. The more aggravating issue is that WordPress (stupidly, IMHO) hard-codes absolute URLs for images and other media into the database fields for post content. If you upload a new image to a blog post while using CodeKit's internal server, the image URL will be saved into the database in full as http://[machine name].local:5757/wp-content/uploads/some-image-file-path.jpg — this image will then be 404 Not Found when trying to visit the "real" site at whatever.dev

Apart from a solution of "disable CodeKit when you're in the WordPress dashboard", any advice on how this could be made better? Or are we missing something in the CodeKit configuration?

Thanks much for the CodeKit rewrite and investigating these issues!

[staffanmowitz]

I've experienced the same problems.

[marknotton]

I'm experiencing identical issues at "adamnorwood". Did you ever find a solution?

The first Code Kit app's biggest selling point was the ability to assign alias's and/or server names within MAMP as I wanted. Now I'm being forced to use Code Kit 2's sever address names. Adjusting the External Server Address name seems entirely pointless.

Bryan Jones, please bring this KEY feature back!

[bdkjones]

Ok. The issue is that CodeKit replaces URL components when the connection is:

[origin server] ------> [CodeKit] ----X---> [Browser]

The solution to deal with Wordpress's "special" nature is to reverse this process and replace the changed address "my-mac-name.local:5757" with the external server address during POST and PUT requests back to the origin server:

[Browser] ---------> [CodeKit] ------X-----> [Origin Server]

In theory, Wordpress should respond to the "Forwarded-For" HTTP header to figure this out for itself, but that doesn't appear to be going on. I'll have to step in and take care of it manually. I'll get this done in the near future.

[marknotton]

I feel like one of those winey, unappreciative, people who just moan. I do really enjoy Code Kit and don't know where I'd be without it. It's just this one feature is frustratingly critical for our developers.

So I really appreciate that you're willing to look into this again. Thanks you!

[thartl]

I am experiencing the same issue with links being rewritten in post content. Running Database search and replace allows me to reverse the changes and keep using CodeKit and WordPress together. Which is great, developing without CodeKit is like going back to dial-up. Thanks for a great app!

[ghost]

I have to face the same problems and can't find the way to get it working anymore. The last times I just played around until the magic happened and it worked. But now, as I had to save the "global settings" in WordPress again, I have the same issue. Any advice how to fix that for the moment, at least?

I got it! :) I changed the siteurl- and home-URLs back to the once provided by MAMP.

[steviehype]

I can confirm the same issues. I didn't realise the URLs had changed in the general settings and changed the local time. After saving my time changes and unknowingly the URL, I couldn't access the home page.

Changed the URLs back to my localhost and saved, although what is shown is still the codekit server URL the site now works.

Frustrating amount of time lost working this out!

[adrianvalenz]

When you change your URLs back to the correct localhost (not codekit's external server) just make sure you are doing it from your localhost's address.

[wesstong]

I WAS very happy with this app, but i lose one week of work because of this ...... And i ve to show the website today, i go to general setting for the slogan and pouf ....... Frustrating amount of time lost !!!!! Please give a solution because when i put the correct localhost, all my picture gone.....

[bdkjones]

I'm sorry, but I can't understand that comment.

Please post a detailed, clear description.

Sent from my iPhone

On Sep 12, 2014, at 10:32, Wesstong notifications@github.com wrote:

I WAS very happy with this app, but i lose one week of work because of this ...... And i ve to show the website today, i go to general setting for the slogan and pouf ....... Frustrating amount of time lost !!!!! Please give a solution because when i put the correct localhost, all my picture gone.....

— Reply to this email directly or view it on GitHub.

[robrecord]

Sounds like he's describing the fact that his image URLs are hardcoded with [machine-name].local after this issue, hence can't see his images.

wesstong - you will have to do a search/replace on your server DB. You can get a PHP script to do this. find [machine-name].local:5757 and replace with the correct host.

[Veraxus]

@Wesstong

There are several ways to correct absolute urls in a WordPress install. Since this is frequently needed when switching between development, staging, and production environments, it should REALLY be old hat for any WordPress dev, but here are two easy fixes...

1. Using a SQL query, you can run a find/replace on any table column. The following boilerplate SQL will fix your post content ( wp_posts.post_content ), but can be easily customized for other tables and columns as well (wp_postmeta.meta_value, wp_options.option_value, etc).

UPDATE wp_posts
SET post_content = REPLACE (
    post_content,
    'FIND STRING HERE',
    'REPLACE STRING HERE'
);

1. If you want a more comprehensive one-step fix, export the database as a SQL dump, run find/replace on the SQL file in your favorite text/code editor to replace the old/incorrect domain(s) with the correct one, and then re-import the "fixed" SQL back into the database.

If you don't already have a good tool for working with your databases, I highly recommend Sequel Pro, which happens to be free. http://www.sequelpro.com

[adamnorwood]

At the risk of veering too off-topic, using simple search and replace when changing URLs / domain names in a WordPress database as @Veraxus describes is actually problematic: there are a variety of things (post meta, widget settings, custom theme options etc.) in WordPress data tables that are stored as PHP serialized strings, and your site will break in subtle ways if the replacement data string is a different length than the search string. Gee thanks WordPress and/or clunky PHP serialization notation! (I'm not trying to pick on @Veraxus's answer…just hoping to prevent future developer sadness…)

The Codex guide to Moving WordPress offers more insight, but most developers I know handle migrations using one of two tools: the ever-popular SearchReplaceDB script or the excellent WP DB Migrate Pro plugin.

On-topic: I hope this issue gets resolved soon! I haven't been able to recommend CodeKit 2 to WP folks because of the change in how the reload server works (our team has switched over to Grunt, but CodeKit still makes a lot of sense for many developers).

[wesstong]

Sorry for my comment a bit aggressive, but I was particularly angry against codekit. I thought it was more neutral, it did not affect the addresses. So in my sql database I found localhost: 8888 and localhost: 5757, it changed the adresses of images, but I still learned some things with that !

Actually i applied the sql script to replace the addresses, and I had to go to localhost: 8888 to change the address of the site in general options of wordpress.

But I think moving to grunt or gulp, which seem more neutral (I needed an autorefresh, a minifier and a sass interpreter)

Again, sorry for the comment, but stress has invaded me :), and sorry for my poor english ;)

[robrecord]

Great tips, guys; we all learned a thing.

[alpinelakesdesign]

Hi Brian, I'm wondering if you have had a chance to address this problem with the Preview function changing WordPress site URLs? Thanks.

-- Lee

[bdkjones]

I haven't read the thread in a while, but CodeKit should not be affecting site URLs in WordPress as long as you're not uploading any content through the WP admin area while viewing the site on CodeKit's preview server.

For now, view the external server address directly when you need to upload content (such as images) to WordPress.

[alpinelakesdesign]

Thanks for getting back to me, Brian. I'm not uploading any content. I'm just working on CSS through SASS. But it's changing the site name and any use of the word used as the MAMP Pro URL.

-- Lee

[bdkjones]

Yea, this happens when you don't use a fully-qualified URI as your external server name.

Wrong:

Http://someproject

All instances of "someproject" will be replaced with CodeKit's internal server address. CodeKit does not parse the document; it just string-replaces because that's much faster and fine for a dev environment.

Right:

Http://someproject.dev

Now, only instances of "someproject.dev" are replaced.

Sent from my iPhone

On Feb 3, 2015, at 11:33, alpinelakesdesign notifications@github.com wrote:

Thanks for getting back to me, Brian. I'm not uploading any content. I'm just working on CSS through SASS. But it's changing the site name and any use of the word used as the MAMP Pro URL.

-- Lee

— Reply to this email directly or view it on GitHub.

[alpinelakesdesign]

That's good to know. I think about half of the problems in these earlier posts have been cleared up with this piece of information. I've been trying to solve this problem off and on since 2.0 came out, and I've never seen this caveat.

Thanks!

-- Lee