As this plugin is referenced in the issue, we might be able to use it as an example?
James Nylen
· October 12, 2018 · 05:53
I wouldn't say this ticket was ignored: it has multiple patches, and helpful commentary from lead developers on characteristics of a good implementation.
We can look at that plugin as an example, but a better example is probably the existing patches on the ticket.
Also, I think the only reason this would need to wait until ClassicPress v2 to be implemented is lack of development time. It's not a user-facing change, and it's an optional security improvement for the likely highly technical users who would go looking for it (people who are purposefully hosting their database on a separate server from their sites).
So if we can get an implementation with the ability to instantiate other, differently-configured wpdb objects after the initial call, and with good automated tests, then I think we should accept it for v1.
Simon Pollard
· October 12, 2018 · 07:59
Yeah I am just thinking as the web modularises (is that a word?) the separation of database and site files will be a common thing. So a secure connection between the two should be standard if not even expected. If this features in any release it would be great :)
James Nylen
· October 16, 2018 · 20:44
If I were implementing a separation between web and database servers as a web host, I'd probably use a secure VPN to enable communication with the database. This way the traffic is encrypted by the VPN.
If I'm setting up a small- to medium-sized site, I'll just put the database on the same server as the site files.
So I think this serves a pretty specific type of user: someone who is setting up a complex install on their own servers. This type of user is also more likely to need a separate $wpdb connection with different settings, as mentioned in the WP core.trac ticket.
If that generally makes sense, this is a pretty niche improvement that should be optional, but still a good thing to support, IMO.
As this plugin is referenced in the issue, we might be able to use it as an example?
I wouldn't say this ticket was ignored: it has multiple patches, and helpful commentary from lead developers on characteristics of a good implementation.
We can look at that plugin as an example, but a better example is probably the existing patches on the ticket.
Also, I think the only reason this would need to wait until ClassicPress v2 to be implemented is lack of development time. It's not a user-facing change, and it's an optional security improvement for the likely highly technical users who would go looking for it (people who are purposefully hosting their database on a separate server from their sites).
So if we can get an implementation with the ability to instantiate other, differently-configured wpdb objects after the initial call, and with good automated tests, then I think we should accept it for v1.
Yeah I am just thinking as the web modularises (is that a word?) the separation of database and site files will be a common thing. So a secure connection between the two should be standard if not even expected. If this features in any release it would be great :)
If I were implementing a separation between web and database servers as a web host, I'd probably use a secure VPN to enable communication with the database. This way the traffic is encrypted by the VPN.
If I'm setting up a small- to medium-sized site, I'll just put the database on the same server as the site files.
So I think this serves a pretty specific type of user: someone who is setting up a complex install on their own servers. This type of user is also more likely to need a separate
$wpdb
connection with different settings, as mentioned in the WP core.trac ticket.If that generally makes sense, this is a pretty niche improvement that should be optional, but still a good thing to support, IMO.