johngoold

The valid markup is shown in the BEFORE code. Clicking the “Update” button results in the markup being changed as in the AFTER code. The “closing paragraph tag, but you’re missing an opening one” that you quote, is from the AFTER code.
That is the problem.
One doesn’t need to preview changes in order to do a save (“Update”, “Save as Draft”…). I actually have a separate computer with its own monitor that I use to view the website (so, on that other computer, I’m not logged it to WordPress and see the display EXACTLY the way a website visitor would).
Thank you for the link. If the plugin isn’t a crude band-aid solution like the 1/2-dozen or so I’ve looked at so far, I may give it a try. However, I still feel, very strongly, that the idea of having an HTML Text Editor in WordPress is to store one’s markup EXACTLY the way it was coded — broken or otherwise.
Similarly, if the markup is valid, then saving it and then opening the page (or post) with the Visual Editor should not break it either.

I also would like to know what the root problem is. It seems to be more than just the use of the wp-cron instead of unix/linux cron.

4.8.2 is just the release of WordPress that we are currently running.

Networked WordPress (any recent WP release) is, more or less, the version of WordPress that is used on wordpress.com. An earlier version (before it was incorporated into core WP) was called Multi-Site WordPress.

It allows hosting multiple, separate blogs with one WordPress installation. The separate blogs can be accessed in two different ways (you have to decide which you are going to use when you create the site).

1) Using sub-domains (which is what I set up). So john.example.com would be one blog “site” and theoff.example.com would be a different blog site.

2) Using a directory (folder) structure. So the previous examples would be example.com/john/ and example.com/theoff/

Cheers,
John

The actual question is still valid, but the reason I asked isn’t.

I disabled Akismet on a test site and the problem persisted.

That may not be the problem. I’m here because I’m trying to find out whether this (I’ll give my description below) is caused by a recent WordPress (or Plug-in) update or something my hosting provider has done.

I’m maintaining a Networked WordPress 4.8.2 site for a client on the same hosting provider as I use for some other sites, including a personal WordPress 4.8.2 (not Networked) site. Though both are on the same hosting provider, the two accounts are hosted on different servers. The two sites have different sets of plugins (with overlap, of course); however, mine only has two: Akismet Antispam and Simple Shortcodes. The only one updated recently is Akismet Antispam.

A “Live Chat” discussion with the hosting provider has them swearing (figuratively) that they have made no recent configuration changes and the load on the server has not undergone any significant change (I’m not sure how much I trust the latter statement).

The problem is getting the “Missed schedule” status (hence not Published). This occurs despite visits to the site (I’ve been testing and working on this problem for two days).

[Updated to turn on notifications of follow-up replies.]

I have just encountered that problem (2017-09-29 & -30). The post scheduled for yesterday showed up with a status of “missed schedule”; the one for today just showed as scheduled. I fixed both manually.

WP 4.8.2 Networked.

As with “theOff”, scheduled publishing has been working for months on this site (well, years, but the site has only been on its current hosting provider for about a year). There is one blog (NB. this is a Networkded site, a.k.a. Multi-blog/Multi-site) that has scheduled posts for every day of the year (a bridge column).

There’s probably an import feature somewhere, but if there isn’t (or nobody can tell you where it is)…

I assume you backed-up your old site before the rebuild, including the WordPress database.

Extract the wp_spidercalendar_xxxx tables from the backup and import them into your new WordPress database (if necessary, first delete the initial ones created by installing spider calendar). If your WP prefix is not “wp_”, make the necessary adjustment. I see 5 of these tables in my database. They are called:

wp_spidercalendar_calendar
wp_spidercalendar_event
wp_spidercalendar_event_category
wp_spidercalendar_theme
wp_spidercalendar_widget_theme

If you have the paid version, there may be others (I don’t know).

I occasionally get this problem, but not very frequently. I think it has something to do with my hosting provider.

Which hosting provider are you using? I’m curious if it is the same one as I’ve not had any luck getting them to resolve the issue.

I think you are using the wrong approach to hosting two websites on a single web hosting account. You should be using some kind of “add-on domain”. If you are using an inexpensive hosting provider, you may not be able to do that, but I think most give at least some ability to handle add-on domains.

If you take that approach, then site1.com and site2.com resolve to their own directories and you can handle Page Not Founds appropriately.

I am having difficulty understanding your setup.

I assume your VPS is running Linux and has an Apache web server running.

Where does mydomain.com point? I mean, where (what directory) would I put an index.html file so it would display if I attempt to go to mydomain.com?

In your post, it seems that is the location you installed your WordPress Networked Multi-site. Because it is a sub-domain installation, then you have blog sites with URLs such as, abc.mydomain.com and xyz.mydomain.com.

If I understand your problem correctly, you need to use server.mydomain.com for some other purpose. Am I correct?

Concerning the certificate renewal: You should be able to upload the CA files to the cPanel (depending on what functionality your hosting provider gives you). I have had cases where I could upload certificates via the cPanel (from my computer, not the server) and others where I had to put them in a “trouble ticket” to my hosting provider’s technical support staff.

If you reply, just reply in Spanish. If I have any trouble reading your reply, I will use Google Translate.

Do you allow people to register themselves for blog sites or do you create them on request? If the latter, just set it when you create the blog site.

Do you want to limit the themes available? You can “Network Enable” or “Network Disable” individual themes in Network Admin (and delete or add themes in the primary site).

I use a sub-domain installation of WP Networked Multi-site. When I attempted to use HTTPS, there was no problem with the “main site” (example.com). When I surfed to it using the https:// prefix, the site was displayed and https:// appeared in the URL entry area.

However, I got a failure when attempting to go to any of the blogs (e.g. some-blog.example.com). That is because one needs a wild-card SSL Certificate (i.e. for *.example.com)

The networked setup has no place in the Settings–>General to enter the site URL. It appears smart enough to continue to use whatever protocol (HTTP or HTTPS) that you used to surf to the site in the first place.

Are you using a sub-directory or sub-domain WP Networked Multi-site installation? If the latter, the SSL Certificate has to be for *.your-domain.TLD

Are you using a sub-directory or a sub-domain implementation for you WP Networked Multi-site? I prefer using sub-domains, but you have to be very careful about redirects.

• This reply was modified 7 years, 6 months ago by johngoold. Reason: Incorrect information about General settings

Do you have a sub-directory or sub-domain type of installation? Personally, I only use the sub-domain type of install, it seems cleaner.

Double-check your wp-config.php file and make sure it hasn’t got mucked up.

For what it is worth, apart from some file compression rules and one moved file requiring a re-direct, I only have the following WP rules in my (well, my client’s) .htaccess (note especially the absence of the rule putting a slash on the end of wp-admin):

# uploaded files
RewriteRule ^files/(.+) wp-includes/ms-files.php?file=$1 [L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule . index.php [L]

For what it is worth.

@jhnpldng Have you resolved your problem?

It sounds like you understand how the Networked Multi-site tables are named. In particular, note the table prefix (it defaults to “wp_” if you don’t override it). The blog_id is appended to the table prefix and an underscore added when creating the table names for the individual blogs.

For example (using the default table prefix), the tables for the blog with id “11” will be called:

• wp_11_commentmeta
• wp_11_comments
• wp_11_links
• wp_11_options
• wp_11_postmeta
• wp_11_posts
• wp_11_termmeta
• wp_11_terms
• wp_11_term_relationships
• wp_11_term_taxonomy

The primary site (the one created automatically when you install WordPress) has those tables without a blog_id in their names plus the following ones:

• wp_blogs
• wp_blog_versions
• wp_registration_log
• wp_signups
• wp_site
• wp_sitemeta
• wp_usermeta
• wp_users

You can use wp_blogs to find out the blog_ids of active blogs. All others, if any, are left-over artifacts of deleted blog sites.

Now the question is whether those old plugins you mentioned (pmpro and wpforo) were multi-site friendly or not. Did they create tables with the WP table prefix and blog_id (and presumably a name that identifies the plugin)? Or did they just create their own tables with, for example, prefixes like “pmpro_”? My guess is the latter (to avoid any possibility of a future clash with a new WP table).

It strikes me you have two choices to clean up your database:

1. Go the route you started and delete all the tables associated with the two old plugins. Scanning the table names should enable you to be able to identify them — I assume you’ve figured this out as you say you have already deleted a bunch of tables (presumably without breaking your Networked Multi-site installation).
2. Another approach, would be to export only the tables for the active blog sites (and the base site, of course) plus those tables created by other plugins you are using (excluding the two old ones).

There are various ways of testing, depending on how long you are prepared to have your site unaccessible. My preference would be to set up a test WP Networked Multi-site using a copy of your database and do all the testing on it.

You should backup your database before attempting major changes, such as this. That way if things go wrong, you can simply restore it.

By the way, I found that using phpMyAdmin to access the database and running the Optimize Table command on all (or most) of the tables, had an incredible effect in reducing the database size.

• This reply was modified 7 years, 6 months ago by johngoold.

Regarding tnkaoua’s comments on the User Interface, I have a two comments (I only use the month view, so have little experience with the week and list views).

I have no issue with only showing events for the month selected (month view) as I can trivially view the preceding or following month if I want to see those events. However, I was surprised the extra days being displayed did not show events. There are two solutions: (1) Show events for those days; (2) Leave those days totally blank (i.e. don’t show the date in the spaces for days outside the current month being displayed).

I too feel that date formats should be consistent throughout. If a short format is used (one that only shows numbers for the day, month and year), I have a very strong preference for the ISO date format (YYYY-MM-DD with other acceptable separators).

Cheers,
JRG