Sara

@lchesna72 can you clarify if you are self-hosting or using a hosting provider? If you’re using a hosting provider, they should be well-equipped to help you regain access to your site’s admin, and debug issues like a broken theme or conflicting plugins.

That being said, I was able to access https://lucyskitchenofrecipes.com/wp-login.php, so you might be able to get to the admin by logging in, and then visiting a specific admin page rather than just /wp-admin.

Ultimately, it is probably an issue with a plugin or theme. There are several other threads on this forum that describe similar blank wp-admin problems, which came down to a plugin or functions.php issue. This will mostly be relevant if you are self-hosting, in which case, try to undo any recent changes to your site’s PHP code, manually reset plugins, and so forth (additional steps are described in the linked threads). Otherwise, your hosting provider should be able to help you fix the issue. If you are self-hosting and need further assistance with resetting plugins or undoing theme changes, I’m happy to share more links describing the process to follow.

Hi Frank. This is a public forum, it’s best to edit your post and remove the email addresses you listed. Some spammers crawl popular websites to find emails to add to lists.

As for the problem itself, have you tried the steps in the documentation to troubleshoot password emails not sending? If not, please try those. If you’re self-hosting on your own server, the issue is likely to be something with your server’s sendmail configuration. If you are using a hosting provider, then you’ll need to get in touch with their own support, typically email configuration is handled closely by WordPress hosting providers. The documentation link I shared explains these details to help you figure out where the problem is. If you are indeed self-hosting on your own server, the troubleshooting documentation links to this related forum post in particular for information about email sending.

Sounds good. In the meantime, if you have some minimal example of XML that reproduces the behaviour and share it, I can try to help you find an import-side workaround.

• This reply was modified 3 months, 2 weeks ago by Sara.

Gotcha, thanks for the code, that helped a lot.

The issue in your code is that it extends, but never calls the parent model’s template function. That’s a problem if there are other plugins extending the same model, because your code will never run theirs (even though it is indeed extending that model). Backbone does not automatically merge the results of the parent model’s template with that of the extended model.

Here’s an example of code that does work with multiple extensions of the same model:

function someOtherPlugin() {
	wp.media.view.Attachment.Details = wp.media.view.Attachment.Details.extend({
		template: function (view) {
			console.log("some other plugin template: " + Date.now().toString());
			const html = wp.media.template('attachment-details')(view);

			return '<div id="other-plugin-extend-details"></div>' + html;
		}
	});
}

function myPluginExtendDetails() {
	const previousAttachmentDetails = wp.media.view.Attachment.Details;
	wp.media.view.Attachment.Details = previousAttachmentDetails.extend({
		template: function (view) {
			const html = previousAttachmentDetails.prototype.template.apply(this, arguments);
			console.log("TEMPLATE EXTEND A: " + Date.now().toString());

			return '<div id="my-plugin-extend-details"></div>' + html;
		}
	});
}

document.addEventListener('DOMContentLoaded', () => {
	console.log("and here :)")
	if (!wp?.media?.view?.Attachment?.Details) {
		return;
	}

	someOtherPlugin();
	myPluginExtendDetails();
});

The important change is to call template of the “previous” attachment details. Given both instances are assigning to the same wp.media.view.Attachment.Details, you need to cache a reference to the previous wp.media.view.Attachment.Details so you can call its template function during your own extension. Hopefully the other plugin also does this so that the order of execution of the plugins doesn’t cause an issue.

The above code results in both of the new divs appearing in the attachment details sidebar of the media model in the editor. If you replace the call to previousAttachmentDetails.prototype.template.apply with wp.media.template('attachment-details')(view);, as your reproduction example shows, you’ll see that only the my-plugin-extend-details div appears in the resulting HTML.

Let me know if that helps, and here’s a link to Backbone’s documentation on the extend function for reference, which includes a note regarding “super” calls in Backbone models.

Have you looked into using WordPress in Multisite mode? It’s not clear from your question whether you’re already doing this, but if not, it solves most of your questions by treating them as you would for a single WordPress installation.

Learn WordPress has a good introductory page to Multisite: https://learn.www.ads-software.com/tutorial/introduction-to-wordpress-multisite-networks/

A quick search online revealed many popular hosting sites that also share tips on administering a Multisite install. This one from Hostinger, for example, claims to be a “complete guide”, so might be the place to go after you’ve read through the documentation on Learn. To your first question, they’ve also got recommendations for a few helpful plugins in the guide in this section later on.

Multisite should solve your questions 2 and 3, for example, if you treat the installation like you would any other single WordPress installation. All sites are kept up-to-date so long as the WordPress installation is up-to-date. Backup the entire WordPress installation, and all sites in the Multisite network will be backed up in the same single process.

As for question 4, I’m unsure. More details might help. Do you mean you need to synchronise content across the different sites?

Can you share a method to reproduce this situation? It would seem like two separate instances of that expression should work. The second .extend would be calling it on the result of the first call, not the original Attachment.Details, so they “should” build off of each other in series, unless they are somehow interfering with each other. Seeing the specific situation and being able to debug it would help find an answer.

I found this trac ticket (via a StackExchange answer) that seems to indicate a good place to start: https://core.trac.www.ads-software.com/ticket/14818

It looks like you can prevent the extra escaping on import by setting that filter to return false.

add_filter( 'force_filtered_html_on_import' , '__return_false' );

Have you confirmed whether the escapes are present in the exported XML? If changing that filter doesn’t work, then the source of the problem might also be in the export format. In which case, it would be best to ask WordPress.com’s support for help.

Issues with the WordPress.com follow button generator should be taken up with WordPress.com’s support: https://wordpress.com/support/

There is a link at the bottom to get in touch with WordPress.com’s support folks.

For what it’s worth, if you’re pasting the HTML into a WordPress post and haven’t granted permissions to enable unfiltered HTML from your user, then WordPress is going to strip the script tags. The snippet you’ve shared is missing the script tags that the generator includes. The script tag is necessary to tell browsers to view the JavaScript code as code to execute rather than just regular text. You can read more about the unfiltered_html user capability in the documentation for it, but be aware that there are potential and significant security issues if it isn’t applied carefully. Enabling that would stop the site from stripping the script tag.

It looks more likely to be an issue with the Nginx configuration rather than WordPress itself, based on the 404. Can you confirm that your Nginx configuration is set up to properly forward requests to WordPress? Just in case, here is WordPress documentation on Nginx usage that may be helpful.

@josiahschaefer, can you share the code you’re using to attempt this? That would help for someone else to be able to reproduce the issue and find out whether there’s a solution or potentially a bug.

Hi Ian,

The error you’re seeing comes during the multisite username verification in the REST API. Usernames must be at least 4 characters long.

You can see the code for this (and all the other conditions for usernames) here, in the wpmu_validate_user_signup function:

https://core.trac.www.ads-software.com/browser/tags/6.0.2/src/wp-includes/ms-functions.php#L496

Based on the code it seems that the error should have included the specific issue in the response. If that wasn’t the case it may be worth opening a Trac ticket for that so that these errors are clearer for folks who aren’t reading the codebase.