ClassicPress Mu. Big surprise when installing a multisite

[iljester]

I was testing a plugin in the multisite version of ClassicPress and installed a multisite locally. And since I also wanted to test it on WordPress, I did the same, but while ClassicPress gave me the possibility of installing the multisite even with a port address, WordPress prevented me. Which of the two is right?

I agree with ClassicPress, because local testing sites often use ports anyway. Thanks guys.

[Ciprian]

After a quick search, I found this:

“After you switch to multi-site or create a new site, you need to go to your database admin page (e.g. phpMyAdmin) and fix the blog’s domain in the wp_blogs table. Basically WP failed to add a colon between the host and port; just have to add it → localhost8080 becomes localhost:8080. Then on the site’s settings add the missing colon to the Site URL and Home URL”

I remember is messed up the host for me a long time ago, but I don’t remember if it was the port or somthing else.

This ticket might also explain why:

#21077 (Add support for custom ports in multisite site addresses) –...

Also, an old article here:

WordPress: Running multisite on different port - Benohead's Software Blog

[iljester]

Thanks @Cipriani. I’m honest: I haven’t done any research on this and your suggestion will allow me to test plugins on WordPress too. However, I wanted to point out that ClassicPress seems to have fixed that limitation, because it is a limitation. The message makes it clear: you cannot install a multisite in a port such as :8888. Therefore it is a precise choice by WordPress that ClassicPress did not make.

[Ciprian]

Yeah, that’s true. WordPress didn’t bother with making sure all edge cases are working, so they just restricted the port.

ClassicPress allowed it, but you should be cautious.

I never use ports myself, I use my production server for development. Some obscure subdomain, or subfolder, so I can show it to the client, in case I need it.

For example: client-dev-1.domain.com, client-dev-2.domain.com and so on.

It’s easier then to put live, as I can just move the files on the actual server, instead of uploading from local.

[iljester]

I, however, have two levels of development:

1. I start by developing a theme or plugin on a local site (which normally has the port). This allows me to easily create commits of files on Github and not have too many problems with updating files on a remote server.
2. Once the theme or plugin is working (you could say after the theme or plugin has passed the alpha phase), if it is a commissioned theme or plugin (but even if it is not), I proceed to install it on a live demo site (exactly like yours). This allows me to do what you said and see how it goes.

[Ciprian]

Sounds good.

I have my own battle-tested theme, which I use for all my clients. It’s light, minimal styles, and it allows for any block plugins out there. I will make it available, at some point, for ClassicPress, like you did with yours recently.

[iljester]

Well. I can not wait to see it.

[Simone]

I’ve backported an unmerged track ticket times ago for the need of testing multisite with MAMP or like.

Edit: this is the PR:

Support Ports on Multisite Domains

[iljester]

Good! You did very well to allow it. Local development and testing are essential, even for a multisite. Moreover, just today I was reading a benchmark on the comparison between CP and WP, ​​and CP beats WP across the board: performance, lightness, etc. (I’ll post it if you want). This further possibility makes CP highly competitive.