aloeroot

Hi there Stef and Animesh; I was getting the rest of the site ready for launch, but today I’m working on this again. As Animesh suggested, I just clicked “create a fresh connection” on the production site, and Jetpack has been disconnected from the staging site.

The new site is ready to go live as of today, so is it better to have you attach the data to the production site now, knowing it’s about to be replaced by the staging site, or take the staging site live first and then reattach the data?

Thanks very much for your assistance.

Thanks very much, Animesh. I’ll take your advice as far as disconnecting and deleting from the staging site (already done), then disconnecting and reconnecting to the production site for now.

It is the Jetpack subscriber list we’re most worried about, yes.

I’m hesitant to disconnect the production site from Jetpack until I’m sure we can reconnect it. We use it for various WooCommerce services as well as the standard Jetpack services.

On the Production site, I’m seeing “Site Connected” and “User Connected (Owner)” under Connection when I’m logged in, so I’m assuming Jetpack is connected to my own WordPress.com account. It doesn’t show up in my list, but I’ve connected a lot of client sites to Jetpack and I’m hoping the list is just limiting the number of sites visible.

The staging site address is https://dev.tla-temagami.ca/ (hidden behind a placeholder for now). As of this morning I had already disconnected and deleted Jetpack from the staging site, so you may not see it in your list.

Thanks again for your help.

Just to follow up on this, I’m aware that this is going to be from a 3rd-party service used by us in our self-hosted .org scenario. I’m just wondering if anyone else recognizes the name so I can get some leads for tracking this down.

We don’t have any commercial plugins currently installed that might be the reason for the charge, and we haven’t received any renewal notices. The Kbenhavn indicates the charge is from Copenhagan so I’m hoping someone might recognize this and be able to suggest a maker who might be located there.

Ah, thank you. I’ll pass this on to the client. Appreciate your help.

Yes, thanks, I found that link. Clicking it didn’t affect the subscriber count on either the site side or the Constant Contact side, but I’m guessing that’s because we didn’t fully capture any subscriptions between the 19th and yesterday.

The list in question is still connected to CC as of today, so I think that part may be resolved. We can consider adding the recent subscribers manually.

Thanks for your help.

Thanks Steve – it appears to be working now. For the record, I had to uncheck the “enable future action” button and re-check it, and then the errors disappeared from the Posts list. A test expiration worked on schedule, and everything appears fine now. Much appreciated.

Hi Marcel – thanks for your help with this. Had to dig for the error logs because they’re in an odd spot on this server. I was getting memory limit errors with meta.php – raised the memory limit significantly on the server and then I was able to reactivate the plugin. Seems that it’s using a bit more memory than previous versions, but it’s functioning again, thanks.

Here’s a link to the screenshot, thanks.

Nothing helpful to add other than a thank-you for sorting this. Thought I was going mad today.

Thank you! They were disabled under the General tab, while enabled under their own. Greatly appreciate the fast response.

Same issue with WPS Hide Login on one of my sites.

Thanks – if you do change them in an update, I’d love it if you’d update this thread so I can remove all the extra files from my child theme. It’s probably better for future compatibility.

Also, I had to change the H3s in framework/widgets/widgets.php to H2s, to avoid a nesting issue with header sizes.

Yes, this is persisting. It’s a child-theming issue, actually. I used the Child Theme Configurator plugin to generate a child theme for this site. With the v1.4.9 update, the child theme develops problems – it looks like a missing style sheet. Reverting to the parent theme fixes the issue.

I think some of your css files must have changed paths with the v1.4.9 upgrade; it’s persisting with the latest release.

I suspect I’m going to have to re-make my child themes, either by scratch or through running the plugin again. I’ll try this when I have some extra time, and will report back.

Further to this, the parent theme is fine. My original child theme, created manually, and the new child theme done with Child Theme Configurator, have non-functioning navigation dropdowns.

I’d hugely appreciate any help you may have to offer on this topic.