cavemanwp

RESOLVED.

Hello again Team. I’m aware that your response time is scheduled for Fridays…a pretty good idea, me thinks.

I’m marking this support ticket “Resolved.” Here’s why:

I’ve learned so much during the last couple of days whilst noodling around with your great plugin, WPSiteSync for Content.

I’ve been able to get a few localhost sites up and running, and this plugin works perfectly in all websites where my WordPress installs have the core WP files installed in the main directory.

That’s enough evidence for me to change my live sites around to be the same WordPress install structure. (WP core files are not in a sub-directory of the domain.) I’m doing that (the sites are pretty new setups–so NBD) so I can gain the use of this plugin.

Website setup structure is less of a priority. I’d rather have the use of WPSiteSync for Content, so I’ve decided to change my websites to obtain the functionality this plugin offers. It’s just that awesome.

Also, I figure that if other well-known and well-respected WordPress products such as ‘DesktopServer Pro’ and ‘WP Migrate DB Pro’ have less or no functionality in a similar WP core files in a sub-directory setup, then I’m guessing there are some serious coding obstacles blocking the way. (I’m not a dev/coder.)

Either way, thanks for a great plugin. I learned a heck of a lot these last couple days digging into things and trying to figure stuff out, so there’s value there too.

Please consider this one less support action item on your plate.

‘</Cheers!>’

more testing…(same system and Firefox browser setup as above)

After plugin uninstsall and verifying delete of …/wp-content/plugins/wpsitesync/… file directories, I checked MySQL database (via PHPMyAdmin) on both live and local sites.

looks like wpsitesync doesn’t clean-up and/or (as seen in further testing) inconsistently cleans up after itself? I saw the following database data on both live/local site’s SQL DB after plugin uninstall:

wp_spectrom_syncHide
wp_spectrom_sync_log
wp_spectrom_sync_media
wp_spectrom_sync_sources

One of the above still had user names/data/authentication token…would that create a conflict if a login password was changed and new data (for the same user-name) was entered into WPSiteSync setup page?

Also, it seems that after entering data into “Password on Target:” entry box…the plugin requires the user to hit “Enter” ?

It seems like the plugin is looking for an [Enter] keystroke as part of a valid password entry…

If the end-user only enters the password and then clicks the “Save Changes” button (without first hitting [Enter] after password entry), the plugin returns the ” Not entered or Username and Password not valid.” However, after hitting [enter] after password entry, and then clicking the (bottom of page) blue update button, I was able to get a handshake/green check-mark.

…however, after the hand-shake via configuration/setup page, I still got the “Target system did not respond with success code.” after a “Push to Target” on my “test post” edit screen.

Other: (1) changed settings to use other user name/password (from live site)…did not get a password/username validation (red x in config settings on localhost site)

(2) tried diff versions of upper/lower/mixed-case on user names…no diff in results.

(3) …oh well. Still hoping and eager to see this great plugin concept working in the near future.

Cheers+

more testing… same Firefox scenario above…

Just created a new user/admin on live site. SAVED/logged-out relogged in (as original admin/user – not as newly created user/admin)

Result = only red “X” on setup entry–both on live site and localhost.

Was wondering if being logged-in on live site made a diff when pushing content to live site, from localhost, using same name/pw as currently logged-in user on live site….

Cheers III

just did some more testing…

fresh install of just-downloaded Firefox, no plugins active…(flushed all local temp directories); my OS is totally up-to-date Win 7 Pro 64-bit

In Firefox:

(1) (made sure wp-content/plugins/wpsitesync dirs were deleted on localhost and live site prior to…) New install of WPSiteSync Content Ver 1.0 plugin on both localhost and live sites. Both sites feature identical sub-directory core-WP-files install…

(2) Entered WPSiteSync for Content – Configuration data in localhost for plugin…success…”Username and Password are valid.” and “green check-mark”

(3) Went to test-post, edit (localhost site)…now see the WPSiteSync box (clean, sharp, nice interface btw!) clicked on, “Push content to Target: https://****.com/****%5Bwpsubdirinstall%5D&#8221; Now get this error message only: “Target system did not respond with success code.”

….very curious indeed.

Q’s: (A) would it make sense, help sync-handshake, to have your plugin enduser manually enter the target website’s “WPSiteSync for Content Site key: ####” into a set-up box on the “Push site” ?? (I see that this is the procedure used by WP Migrate DB Pro prior to a sync)

(B) does it make any difference if the end-user adds a trailing “/” character in the “WPSiteSync for Content – Configuration: > Host Name of Target:” url entry box? (With or without a trailing “/” seems to change the result of the red-x or green-check-box result.)

Cheers II