5 ms·

At a first read through there seems to be a of usefull knowledge and experience in your post. So I’ll surely go through it in detail and take away everything I

At a first read through there seems to be a of usefull knowledge and experience in your post. So I’ll surely go through it in detail and take away everything I can. That being said, unfortunately you have a few assumptions, that makes some of what you write less relevant. > But then many users wont use your service because they cant install the plugins they want. This is sort of the core misunderstanding: This setup is defined for one customer (marketing agency) so I dont really care how the masses would like to use WP hosting. And in extension of this users will not be allowed to freely install plugins, customizations etc. That is want it means for this to be “fully managed” (I wrote about what and how in another comment above). The business need for this thing came about in the first place because the customer didnt not want to be the one to fiddle with webservers, plugins and updates. So the goal is to build something that strikes a balance between enabling the customer to deliver their (marketing stuff) to their clients and doing it in a controlled manner, for an acceptable price. Restrictions and processes are going to drive prices down, while the need for flexibility and time-to-deliver will drive price up. The question is if there exists a balance thats acceptable to all parties. On a more overall level, I’ll add that I get how WP has become a huge ecosystem like you say. But part of why I fint this little project interesting is that, in my eyes, its an ecosystem that has evolved through thousands of low-tech users (certainly not experienced devs) hacking together bad, but somewhat functioning, solutions and making so many bad tech decisions along the way, resulting in a mountain of tech debt which leads to all of the stacked problems you describe in your comment. I think you are completely correct in all the issues you describe, but Im interested in whats possible to do if all the usual ways of doing things in this ecosystem is thrown out the window, and we look at how things should be done. Is it possible that a better solution doesnt exist? Sure! But wont know still we try. There is just so many ingrown “bad things” that seems to be the norm in this WP world, that would not even be considered in a more regular sw development situation: Imagine giving the somewhat “tech savy” end user access to the C# codebase, installing nuget packages (WP: plugins), making code changes (WP: functions.php) and messing with appsettings (WP: configs).. and directly in prod. Its just too far out. I wont even let the senior devs on my team deploy code changes directly to prod. We have git, PRs, reviews, tests, build pipelines, test environments and so on.. We’re not savages. Or, a less dramatic example: a few comments/people have asked now, what I’ll do about “that broken plugin which breaks the site”. Well, I’m not going to use it - its broken!? Just like I’m not using broken python packages.

unity1001 4y ago
> This is sort of the core misunderstanding: This setup is defined for one customer (marketing agency) so I dont really care how the masses would like to use WP hosting In case you missed, I already made an example of that case. It is a workable format in the WP ecosystem and there are many who use it. However, the market for it is limited to the customers whose needs fit the specific features you provide. That said, its definitely possible to establish a small business with that format. But its naturally limited, and in the higher tiers the competition is fierce. > I’ll add that I get how WP has become a huge ecosystem like you say. But part of why I fint this little project interesting is that, in my eyes, its an ecosystem that has evolved through thousands of low-tech users (certainly not experienced devs) hacking together bad, but somewhat functioning, solutions and making so many bad tech decisions along the way That's the perspective mistake what a lot of people who are new into WP make. I thought similarly way back. However as you get immersed in the ecosystem, first you see that things work quite well and they are not merely 'somewhat functioning', and the tech choices made by everyone exactly fit their budget, their needs and what's maintainable. People end up making the mistake of providing 'better solutions' that will surely help the 'bad tech choices' in a given use case a few times. Only swiftly to learn that there were reasons why that particular use-case and its sub-ecosystem developed, and those reasons almost 100% coincide with the business needs of that sub-ecosystem. Case in point: > mountain of tech debt which leads to all of the stacked problems you describe in your comment Being filesystem-dependent never was tech debt. At the point WP and its ecosystem came to being, there was no availability of reliable NFS setups, leave aside anything being affordable for the broad public in any way. Coupled with the plugins needing filesystem features to provide features and enhance the sites, being stateful was a good choice. Today its little different - the majority of WP ecosystem uses plugins and thats why WP is big - anyone needing to any kind of thing can find enough plugins to make it happen. Hence the need for the filesystem. Like you are planning, its possible to identify a narrow set of feature needs and compile a list of plugins and themes to create a rather rigid version of WP and even turn it stateful. But this is a sub-ecosystem of WP and WP would never ever become what it is if it was this limited from the start. In the end, the plugins that you are going to compile into your WP distro will be plugins that were made for use in stateful sites to start with. So in a sense, this is not WP's tech debt - its the Internet technology's tech debt - it was built on stateful apps, and those who were running stateless workloads were few at the dawn of the Internet. When the stateful workload problem is solved (either by K8 or by some other tech) this problem will be auto-fixed. > Imagine giving the somewhat “tech savy” end user access to the C# codebase, installing nuget packages (WP: plugins), making code changes (WP: functions.php) and messing with appsettings (WP: configs).. and directly in prod. Its just too far out That is why no more 'properly done' and 'well engineered' cmses, platforms have never taken off: The flower shop owner somewhere in Oregon or the Japanese blogger in Tokyo needs specific features for his or her website/shop. These are provided by plugins that immediately implement those features to his site at ridiculously low cost and effort. As his or her business scales, things will keep the same rhytm, with solutions that require major monetary and time investment for 'more properly engineered' solutions demanding insignificant investment of money and time from him. Over time, he or she will end up being proficient in this easy-to-use system to be able to run his WP-based site/shop single handedly, whereas similar setups require considerable money and even teams to set up and maintain with 'properly engineered' solutions. Naturally, he will never go near any such solution. > We’re not savages. Thats a very crappy way to look at this. The flower shop owner above will not like that kind of perspective. Neither the rest of the WP ecosystem. Such attitude and arrogance is not well-received. Especially keep it away from any support/comment thread at WP.org. You would get very harshly rebuked. > Or, a less dramatic example: a few comments/people have asked now, what I’ll do about “that broken plugin which breaks the site”. Well, I’m not going to use it Your users would eventually force you to make it happen, or they would just move somewhere else. If youre lucky, some of them would even generate enough noise and feedback for you to notice so that you could address the situation. Otherwise the majority just silently moves on to somewhere else since there are a plethora of WP services for anything. This is before the fact that there are plugins that you have to use even if it breaks some site. Its the providers' obligation to fix it and make things happen. WP is all about making things happen fast and with reasonable cost. In between a service that does things right 98% of the time much easier and with lower cost and one that does everything right and 'properly engineered' 100% of the time, the users will go with the 98% one. The other one won't even enter the picture to be considered. The hardcore reality of real life economics is much different than the reality of the engineering in large organizations in which engineering can be done in specific ways without being able to demonstrate total business justification, thanks to being shielded from the market economics due to the large capital and complexity of such organizations being a wall that separates them. Large marketing clients are much more workable in that regard and that's a good choice. But those large marketing clients will also have demands for features like the general WP users, even if the demand frequency may be much lower than the average. However make no mistake - even if they are larger users/customers who may have been fed up with maintaining sites and plugins, they are still WP users. ... Your approach and attitude reminds me of mine way back. WP ecosystem taught me a lot about the real world, actual business needs, what really matters and changed my entire perspective. Especially interacting with customers/users teaches an engineer like nothing else could. So it will be a maturing journey however you look at it.

unity1001 4y ago

> This is sort of the core misunderstanding: This setup is defined for one customer (marketing agency) so I dont really care how the masses would like to use WP hosting In case you missed, I already made an example of that case. It is a workable format in the WP ecosystem and there are many who use it. However, the market for it is limited to the customers whose needs fit the specific features you provide. That said, its definitely possible to establish a small business with that format. But its naturally limited, and in the higher tiers the competition is fierce. > I’ll add that I get how WP has become a huge ecosystem like you say. But part of why I fint this little project interesting is that, in my eyes, its an ecosystem that has evolved through thousands of low-tech users (certainly not experienced devs) hacking together bad, but somewhat functioning, solutions and making so many bad tech decisions along the way That's the perspective mistake what a lot of people who are new into WP make. I thought similarly way back. However as you get immersed in the ecosystem, first you see that things work quite well and they are not merely 'somewhat functioning', and the tech choices made by everyone exactly fit their budget, their needs and what's maintainable. People end up making the mistake of providing 'better solutions' that will surely help the 'bad tech choices' in a given use case a few times. Only swiftly to learn that there were reasons why that particular use-case and its sub-ecosystem developed, and those reasons almost 100% coincide with the business needs of that sub-ecosystem. Case in point: > mountain of tech debt which leads to all of the stacked problems you describe in your comment Being filesystem-dependent never was tech debt. At the point WP and its ecosystem came to being, there was no availability of reliable NFS setups, leave aside anything being affordable for the broad public in any way. Coupled with the plugins needing filesystem features to provide features and enhance the sites, being stateful was a good choice. Today its little different - the majority of WP ecosystem uses plugins and thats why WP is big - anyone needing to any kind of thing can find enough plugins to make it happen. Hence the need for the filesystem. Like you are planning, its possible to identify a narrow set of feature needs and compile a list of plugins and themes to create a rather rigid version of WP and even turn it stateful. But this is a sub-ecosystem of WP and WP would never ever become what it is if it was this limited from the start. In the end, the plugins that you are going to compile into your WP distro will be plugins that were made for use in stateful sites to start with. So in a sense, this is not WP's tech debt - its the Internet technology's tech debt - it was built on stateful apps, and those who were running stateless workloads were few at the dawn of the Internet. When the stateful workload problem is solved (either by K8 or by some other tech) this problem will be auto-fixed. > Imagine giving the somewhat “tech savy” end user access to the C# codebase, installing nuget packages (WP: plugins), making code changes (WP: functions.php) and messing with appsettings (WP: configs).. and directly in prod. Its just too far out That is why no more 'properly done' and 'well engineered' cmses, platforms have never taken off: The flower shop owner somewhere in Oregon or the Japanese blogger in Tokyo needs specific features for his or her website/shop. These are provided by plugins that immediately implement those features to his site at ridiculously low cost and effort. As his or her business scales, things will keep the same rhytm, with solutions that require major monetary and time investment for 'more properly engineered' solutions demanding insignificant investment of money and time from him. Over time, he or she will end up being proficient in this easy-to-use system to be able to run his WP-based site/shop single handedly, whereas similar setups require considerable money and even teams to set up and maintain with 'properly engineered' solutions. Naturally, he will never go near any such solution. > We’re not savages. Thats a very crappy way to look at this. The flower shop owner above will not like that kind of perspective. Neither the rest of the WP ecosystem. Such attitude and arrogance is not well-received. Especially keep it away from any support/comment thread at WP.org. You would get very harshly rebuked. > Or, a less dramatic example: a few comments/people have asked now, what I’ll do about “that broken plugin which breaks the site”. Well, I’m not going to use it Your users would eventually force you to make it happen, or they would just move somewhere else. If youre lucky, some of them would even generate enough noise and feedback for you to notice so that you could address the situation. Otherwise the majority just silently moves on to somewhere else since there are a plethora of WP services for anything. This is before the fact that there are plugins that you have to use even if it breaks some site. Its the providers' obligation to fix it and make things happen. WP is all about making things happen fast and with reasonable cost. In between a service that does things right 98% of the time much easier and with lower cost and one that does everything right and 'properly engineered' 100% of the time, the users will go with the 98% one. The other one won't even enter the picture to be considered. The hardcore reality of real life economics is much different than the reality of the engineering in large organizations in which engineering can be done in specific ways without being able to demonstrate total business justification, thanks to being shielded from the market economics due to the large capital and complexity of such organizations being a wall that separates them. Large marketing clients are much more workable in that regard and that's a good choice. But those large marketing clients will also have demands for features like the general WP users, even if the demand frequency may be much lower than the average. However make no mistake - even if they are larger users/customers who may have been fed up with maintaining sites and plugins, they are still WP users. ... Your approach and attitude reminds me of mine way back. WP ecosystem taught me a lot about the real world, actual business needs, what really matters and changed my entire perspective. Especially interacting with customers/users teaches an engineer like nothing else could. So it will be a maturing journey however you look at it.