[olug] any WordPress whizzes on board?

[Lou Duchez]

The process in question involves merging the work of two groups that are 
doing different things. One group is developing pages and pages of 
content; the other group is working on fancy home page / look-and-feel / 
headers and footers.  It's two groups operating in different settings on 
different timetables, and we don't want the one group to accidentally 
step on the other group's work.  So when we merge the two WordPresses, 
the pages developed by Group 1 display with the formatting established 
by Group 2.  The process actually works, except for those pesky resized 
images, and occasional font cleanup because Group 1 copied/pasted text 
rather than type it directly into WordPress.

"Is it a cloud server?" - Um, define "cloud server"?  These days, almost 
anything can count as a cloud server.  Groups 1 and 2 are using their 
PCs to browse to WordPress like normal human beings, they're not using 
Citrix or the like.  I don't know if that helps.


> each /site/ doesn't use its own database on MySQL? ie site1 site2 site3 I
> guess I'd need to know more about the setup, but 99% of the time, a
> WordPress move for me goes like this:
>
> 1. tar.gz up the source folder, even if it's cpanel and move to the new
> server
> 2. chown -r apache:apache /var/www/virtual/ on new server
> 3. set up apache virtual hosts and test
> 4. production
>
> I'd think the mapping you are talking about would be handled in MYSQL DB's
> you'd move over, and all the files /should/ be where it's looking if you
> cloned both the DB and the webroot, and kept paths similar.
>
> But someone else can step in and tell me I'm wrong. Is it a cloud server?
> can you just make 2? try and export the info in a backup using a plugin,
> and on the new server try and restore. It's always been super clean for me
> to just do it with the files, less of a chance it'll get screwed up, and
> normally there are just a few prerequisites that need to be installed, as
> in PHP and it's modules. I use centos for everything so for Debian/ubuntu
> the steps are slightly different.
>
> On Fri, Dec 7, 2018 at 3:54 PM Lou Duchez <lou at paprikash.com> wrote:
>
>> Thanks, I think you told me what I want to know.
>>
>> I'm comfortable using Linux for unchallenging operations, like
>> transplanting entire Wordpress so that it behaves identically in its new
>> home (dump the database, zip up the Wordpress directory, transplant, fix
>> .htaccess if need be).  My particular issue involves /merging/
>> Wordpresses, and that's where I worry more about tripping over
>> WordPress's internal mechanisms.  Like, to pull in pages from another
>> WordPress, that for sure needs to be an export / import operation, just
>> for ID and slug management. The database requires finesse, and it's far
>> better to rely on someone in the know (say, WordPress themselves) to
>> manage that.
>>
>> Merging images from another Wordpress /could/ be a nightmare, if there's
>> much or any database involvement.  That's why I'd really like to export
>> / import the images rather than just zip / unzip the "uploads"
>> directory.  The good news is, so far, there don't seem to be any
>> problems if I export / import the images and then zip / unzip any
>> resized versions; Wordpress seems not to feel anything questionable is
>> going on.
>>
>> But that could change at any time, and it sure would be nice if there
>> were a plugin that copied the complete set of images, with at least
>> lukewarm assurances that it was doing things the "approved" way.
>>
>> Honestly, I do not get why this isn't a well-trodden path.  If I create
>> a page, pull in an image, and resize it, WordPress will build a resized
>> version of that image and link  to it.  It follows that, if I'm
>> exporting that page for importing elsewhere, I'm likewise going to need
>> to export the resized image for importing elsewhere.
>>
>>
>>> I own https://reiners.tech, feel free to hit me up if you need some
>> help.
>>> I do quite a bit of WordPress, Joomla hosting for businesses, those
>> clever
>>> workarounds work better than many plugins, which can also backfire.
>>>
>>> Normally when I install WordPress and move a site, I'll just copy the
>>> apache .conf file, and move the entire webroot to the new server, and
>>> `chown apache:apache /var/www/html`  to Apache, and move the DB if need
>> be.
>>> Moving things via command line is not really a clever workaround, it's
>> just
>>> how Linux works. If you use a plugin, you have to rely on it being both
>>> compatible with your version of WordPress, as well as coded right.
>>>
>>> Command line works 100% of the time for me. YMMV but I'd love to help if
>>> you need it.
>>>
>>>
>>>
>>>
>>> On Fri, Dec 7, 2018 at 2:53 PM Lou Duchez <lou at paprikash.com> wrote:
>>>
>>>> Anyone here do a lot of WordPress migration?  In particular, is there
>>>> any way to get WordPress's export / import functionality to migrate not
>>>> only the main copy of an image, but any resized varieties of that
>>>> image?  I'm pretty sure I could just zip / unzip the wp-content/uploads
>>>> directory, but I'd rather operate through WordPress than depend upon
>>>> Clever Workarounds.  Clever Workarounds have a way of backfiring.
>>>> _______________________________________________
>>>> OLUG mailing list
>>>> OLUG at olug.org
>>>> https://www.olug.org/mailman/listinfo/olug
>>>>
>>> _______________________________________________
>>> OLUG mailing list
>>> OLUG at olug.org
>>> https://www.olug.org/mailman/listinfo/olug
>> _______________________________________________
>> OLUG mailing list
>> OLUG at olug.org
>> https://www.olug.org/mailman/listinfo/olug
>>
> _______________________________________________
> OLUG mailing list
> OLUG at olug.org
> https://www.olug.org/mailman/listinfo/olug