Yeah… I generally have always used the ‘migration tool’ from the new server to basically package up old domain, move to new system and expand out the files and folders — normally works. Except this last time, funnily enough (a year ago August). So, tried the DUPLICATOR plugin and went ‘wow’ … then used it again on a site where we changed the domain name from some hideous long thing to short sweet name, and it even did all the internal domain name changes — that was the “whoa!” moment. SO, now I throw out the “try DUPLICATOR” line to everybody, with WP sites.

FTP still works, though. 🙂

Sorry my original post wasn’t simpler — I usually am only here, while waiting for something else to finish here that I have to keep eye on so can’t go for a walk; and thus I end up rambling a bit here, and on Facebook 🙂

Nice thing about WP, is that often stuff gets suggested and then there is a heck of a lot of people to provide feedback, and some stuff gets changed. So, some people like the idea of Gutenberg since it gives WP some native layout support to finally become a CMS vs a blogging platform, but others think it breaks the “keep it simple stupid” aspect; I think the CMS folk will win, because of course Automattic wants this for wordpress.com and for paying clients to actually monetize WP further and presumably since they own WooCommerce, they can build hooks to allow for more control there so people don’t have to edit a function, a template override, etc. just to make come stupid columns in Woo.

All very transitional. Much like other nutty stuff like http/2, ipv6, etc.

2018 will be a pretty big year of change on the interwebs.

Theme doesn’t control storage of the images; that’s done by WordPress media manager.

Often using DUPLICATOR is best way to ‘move’ a website. Also good to FTP the image folder off your old system and ‘compare’ to image folder from new system. If you have 800 images in one and 700 images in another, then migration didn’t work.

Most common issue with this is file naming problems, like

myimage-123.jpg
myimage-123(2).jpg
MyImage-123.jpg

will likely cause a lot of problems in any kind of ‘move.’

Anyway — just feedback from sombebody who’s been moving stuff from server to server every 3 years since 1996 (!).

Upshot: don’t trust the WP export function.

Upshot: if moving from one Plesk box to another, the migration tool will copy everything over properly. If moving from one host to another, other best option is DUPLICATOR plugin.

I guess the point is, that the theme doesn’t immediately affect the “editor page” in WordPress, aside from the single element which the theme has to show the ‘width’ in WYSIWYG mode. The theme doesn’t ‘change’ the post editor, so if core changes the post editor it doesn’t change the functionality of the theme.

So, nothing to worry about.

Having more options for editing a post, is primarily adding more ‘core CSS’ to WP, it doesn’t necessarily mean all pre-existing CSS stops working.

For instance, shortcodes are a function, not a design element. So, any ‘shortcode’ can always be moved to a personal plugin, or functions file, regardless of theme used. Such as a dropcap, as it’s really just CSS with a “shortcode” to call the CSS in the post. That functionality cannot change, as it’s not “unique” to WordPress, specifically, nor its post editor.

Upshot – nothing to worry about this point.

Again, bigger worries are prep for php 7.2, http/2.

Yep, that’s how you update plugin in WordPress.
a) deactivate; delete
b) install, activate

I think the css to make a nowrap span is
.nowrapit{white-space: nowrap;}

I have a barrel of monkeys <span class="nowrapit">99,9999 km</span> ...

Have you tried normal nonbreaking spaces in your HTML ?

You can also create CSS to keep elements together and apply that as a span.

We did that back in 2013 with our main site redesign to ensure our toll free number didn’t wrap on Boostrap section collapse on mobile.

a) disable all minification plugins, caching
b) check for bug in version of Yoast SEO conflicting with page builders
c) clear transients with WP-optimize
d) resave permalinks before using
e) consider adding explicit paths to website in wp-config.php while also increasing default RAM from 40MB to 64MB
f) make sure you clear caching in Chrome if hadn’t been done when switching themes and such with your website
g) disable plugins not included with theme if still having problems
h) TIP: ‘create’ your blank page FIRST, then open it with TD Composer to edit; that’s what I do — can help mitigate php transients and timeouts, where the ‘session’ dies before you actually finish editing and thus page never actually made, so nothing actually happens. Happened to me on one site with php 5.4, but 5.6 totally fixed that nonsense. If you’re still using php prior to 5.6 you’re likely DOOMED! 😉

( food for thought while doing my backups this week; I don’t work here or speak for tagdiv so ignore my ramblings unless it sparks your imagination! )

Try just using one of the page builders or the other, generally not good to use both, in my own experience. Try clearing your caching, try disabling any plugin that was updated that might have “broken” something if it “suddenly” stopped working. Check your system status, etc.

(I don’t work here, just feedback as long time user.)

Why not just disable the them modal; build your own modal with CSS, and replace it with social login option that hooks into WP?

If you need it that badly, hire somebody. It’s not that hard.

Otherwise, as they’ve already answered they will consider it as possible future option, even though it will add a lot of additional support overhead.

Still impressed. …. happy.

I’m more freaked out by upcoming PHP 7.2 … !

Latest supported version included from the downloads for the theme in ‘all files’ zip in the ‘plugins’ folder.

Yeah. I think if they stop using the TinyMCE editor that might cause those issues; which of course will lead people to re-install it as a plugin or something.

So, I wouldn’t worry about it. They can’t justify breaking millions of pages, let alone all the existing wordpress.com ‘hosted’ content!

Much like supporting ooooold php, there would probably be a use case to keep using the old method vs the new one, perhaps via a function or wp-config toggle. Much like one has to register support for bbpress.

I’m sure TagDiv will have an answer if we both stop talking about it 😉

I also don’t follow Yoast, since they are often wrong, and can’t even fix their own plugins half the time. But, that’s also just my own opinion.

Well, then if that’s the case — I stopped keeping up on it several months back due to the outcry from smart people on how dumb it would be to wreck WP for many folks — it’s theme agnostic, so has no bearing on any specific theme, since with the TDcomposer, it’s designed to build ‘pages’ not ‘posts’ which use the normal WP editor.

Obviously, they do need to do some updates since stupidly they were still doing inline styles for stuff like

<p align="center">

which has been deprecated for couple of years now, and should only be done with CSS classes, not inline styles.

SO, hopefully it will work. You can always install a test site to play with the beta right now if you want. I know somebody who did, disliked it, stopped playing with it since it was so terribly buggy; so I didn’t bother.

Anyway — good discussion to start for those into this stuff 🙂

I personally prefer Bootstrap … but that’s me.

Gutenberg is a simple page builder for sites without one; it’s not needed if using TD themes as it includes option for 2 different page builders, including TDcomposer, fully integrated with theme.

A *lot* of developers, WP websites/blogs, and theme companies have already written negative reviews on the beta version and many have requested it *not* be made part of core, and left as a plugin.

Just my thoughts — you can Google the topic extensively; but upshot – it will be useful if using the twenty-sixteen theme (or free themes included with WP), but for most commercial themes it will likely break stuff and you would be “on your own…” with that.

( I don’t work here. )

I did ??

Install only the theme, not the all files zip.

Did you do clean theme install?

And so you also updated wp-config.php to tell WP that it can use that much memory ? You *have* to do that to increase default from 40MB.

e.g.,
define( 'WP_MEMORY_LIMIT', '64M' );

You might find it useful to review the actual documentation for WordPress, as it’s a great place to learn how things work ‘under the hood’ as it were:
https://codex.wordpress.org/Editing_wp-config.php#Increasing_memory_allocated_to_PHP

• This reply was modified 8 years by simchris.

I think you can email them along with your purchase code and the website URL where it will be used and they can send it to you — also good to learn to keep backups of site versions for future use.

Point was – theme has nothing to do with who ‘likes’ your page. It’s just grabbing that info from Facebook. You need to login to your FB app page, or create an app, or similar on Facebook to track anything. Any and all data is on Facebook – not your site or the theme.

So need to read up on Facebook on how the like/share tracking actually works! 🙂

You need to increase the memory to 64MB or more in both your hosting setup and in your wp-config.php file. Common solution when using complex page builders. Google it. 🙂

Theme would only have those pages there if
a) you’ve imported demo page content
b) you’re using translation plugin to build alternate page versions

Ideally clear all caching, remove all demo content, resave permalinks, clear all transients with wp-optimize; check you htaccess for old redirects — in case you have old redirects going someplace for stuff not actually there.

Force resave your sitemap; resubmit to Google etc.

Pages removed will stop getting pinged eventually. Hurts nothing to get some 404s for temporary pages. Nobody on the web should be linking to temp pages so zero issues for site other than getting temp errors like that.

Not sure that helps – but common issue when you have temp pages, then delete, then have redirects created for non existant pages to near matches; esp if the auto-redirect plugin links to pages you then delete also. Get a bad redirect ‘chain’ going there.

Food for thought.

not sure if this helps: what i did was put default WP search widget in sidebar; then view source, copy/paste the code into text file; edit then place on home page in normal raw html box. Style with custom CSS. no plugin needed.