Hello Team,

Working with a client, I discovered a thing with the staging option that you have which makes it pretty unusable at times.
Let me explain it here,

  1. The customer has a website at domain.com which he is currently redesigning.
  2. He creates a staging website with hoster's subdomain staging.somedomain.com.
  3. Now after the customers has created the website as he likes, when he wants to push the website to live, he cannot select the website at domain.com and needs a new website to be selected. If the customer has a 1 website plan, he won't be able to push the changes to live at all.

What I suggest here is,

  1. The user can select the domain he wants to push the staging content to. The user might add multiple domains under a single website.
  2. So when a user wants to push to live from staging, he will be asked which domain he needs to push the contents to and is he okay that all files will be overwritten. Once he clicks okay the content is pushed from staging to live.

If you have any questions, please feel free to ask.
If the feature makes sense, please upvote!

@PradeepC
it is nearly useless

I sent this to enhance today; core requirements should be prioritized before extras.

Staging:
This should be 100% hands-off. If it isn't, then this priority should be priority 10

not true staging; more of a clone
I'm not saying cloning isn't nice to have, but we need staging

Inability to push staging to production
Without this, why bother doing anything

inability to lock staging to the same server
Sure, maybe we'd want it on a different server in rare cases.

  • waste of time for everyone involved (nothing like waiting 1,2,3 hour for staging from Seattle to Miami for no reason
  • often a complete waste of BW and resources, clogging up the network
  • simplicity for the customer, create staging and push live (fast)

instantly create staging (same server)
instantly push staging to production (same server)
local staging, click a button, create staging, done (not that difficult)
push to production, click a button, swap staging with production (don't even need to move anything)
done, old production now in staging (just in case), and easily removed
production online
not difficult

ability to disable backups on staging
nice to have and ultimately easy enough, disable backups on staging (tick a box done)

auth-based access to staging
should not require .htaccess (non-functional on openlitespeed) and automated.
No staging site should be publicly accessible.

Business Elements
onboarded a large marketing firm in the US today
lost client, first question they asked, "can we make our own staging?"
discussion in 10k facebook page the other day, bashing hosts without staging, forcing website owner to ask

Priority
Hosting company need (the time we waste on this internally even with 100 websites is insane)
Website owner needs

Why prioritize extras vs. core requirements?
This hugely limits my ability to scale websites. Which also affects enhances revenue given the pricing model.

Who else struggles with this???

    My concern with how the staging concept is implemented is that it causes twice the RAM allocation. Sure maybe a staging site won't use much extra CPU but as implemented they consume the same level of resources as any other site, so you are able to allocate fewer sites per server.

    Staging sites should just be subdomains running under the same server process as the primary site. So they may consume a few extra threads, but no additional RAM.

    And of course, should include the ability to essentially one button click to clone prod to a subdomain ("staging" or "dev" or whatever) ... In WordPress, you would really only want a staging-to-prod workflow to move code, not databases... or at least the option not to move the db. Even Plesk which I think has a pretty mature WP Toolkit suite of services has a clone to staging feature, but as far as I know has nothing built in to help you migrate staging to prod.

      digitalexpanse I'd like to add that Having a Staging server role would be beneficial. I prefer not to have the staging sites hosted on the production server.

        And this, in a nutshell, is the problem of "extras" and the issue.

        Ram is cheap, build proper packages with staging limits, and production wise you'd never want a staging or development site under the same container (that's a stellar way to compromise a production site).

        We work on WordPress sites every single day, nonstop. I have no clue if you're just not aware or haven't bothered to look, but modern themes (Kadence, GP, Astra, etc), all store theme designs in the database. We'd definitively want a database creating on staging sites.

        SOP for your Dev, code-only scenario is extremely simple.

        1. clone site, as dev.
        2. drop db, connect to production, dead simple
        3. do whatever you want code wise, rsync to production as needed
          beyond easy

        We truly need to filter out the extras and refocus on the core first.

        jkeegan Staging sites should just be subdomains running under the same server process as the primary site. So they may consume a few extra threads, but no additional RAM.

        There's no reason you couldn't do this with the domains feature however I wouldn't recommend it. Separate websites benefit from complete PHP isolation under Enhance whereas mapped domains do not. As @digitalexpanse correctly said, this could lead to compromise of your production site, especially if a staging domain were forgotten about and not patched.

          digitalexpanse Staging:
          This should be 100% hands-off. If it isn't, then this priority should be priority 10

          I think you might be referring to the ability for Enhance to update the database WP_SITEURL and HOME params. This is coming very soon, maybe in 9.2.0 which is the next minor release.

          not true staging; more of a clone
          I'm not saying cloning isn't nice to have, but we need staging

          The current staging functionality is more of a commercial feature for mass hosting providers. It lets them create a website which is limited to a subdomain of the host's staging domain and doesn't consume the websites resources from their package allowance unless pushed live.

          Inability to push staging to production
          Without this, why bother doing anything

          At the moment the method for this is to move the existing website to a new domain for example old.shop.com then "push live" the staging website onto the original live domain.

          What some customers have made clear to us is that this doesn't suit their workflow and instead they want the ability to copy the contents (files and database) of a staging website (or even another live website) to an existing live website, overwriting the current data but preserving the source website in place. It's almost a reverse clone. We are working on this feature.

          inability to lock staging to the same server
          Sure, maybe we'd want it on a different server in rare cases.
          waste of time for everyone involved (nothing like waiting 1,2,3 hour for staging from Seattle to Miami for no reason
          often a complete waste of BW and resources, clogging up the network
          simplicity for the customer, create staging and push live (fast)

          We are going to add this as a platform setting, "when cloning an existing website, attempt to select the same server". For now maybe a workaround is to use the package server groups feature to limit the customer to a specific server group based on location. That way their live and staging websites will be within a single data centre.

          push to production, click a button, swap staging with production (don't even need to move anything)

          This sounds more like the current functionality except that you have to remove the domain from the existing live site manually before doing this. We have an open feature request to add a "domain swap" function which will remap the domain without first removing it and will preserve existing custom records.

          ability to disable backups on staging
          nice to have and ultimately easy enough, disable backups on staging (tick a box done)

          Feature request logged and coming soon.

          auth-based access to staging
          should not require .htaccess (non-functional on openlitespeed) and automated.
          No staging site should be publicly accessible.

          How do you want to limit it? Do you want functionality similar to CloudFlare zero-trust or do you want to block by IP?

          Why prioritize extras vs. core requirements?
          This hugely limits my ability to scale websites. Which also affects enhances revenue given the pricing model.

          We prioritise development based mostly on customer feedback but taking into account the development complexity vs the potential benefit. The challenge is that there are many different types of Enhance customer - those running a few sites on a VPS, those running large scale mass hosting, software development agencies.

          After a very successful few months we are starting to scale our development team and hopefully this means we can develop all the requested features in a shorter space of time to make sure everyone has the functionality they need.

              Doing new things is fantastic, but you can't ignore the core features to focus on shiny objects, often far more complex compared to the basic scenario I'm requesting for staging.

              I understand, and all this feedback may be part of the problem. And the further you get/move away from the norms, or what I often refer to as best practices, the more this becomes exponentially more difficult for everyone from the top down.

              When you break the mold just to break the mold, you now have to create additional documentation and re-educate clients. Your clients also have to re-educate website owners.

              1. enhance level
                Documentation has never been Enhance's focus. I'm still awaiting documentation on a manual website recovery from a few months back, specifically when the source server is offline and we need to restore the website to a new server.

              2. client level
                Now we have to deal with these new features and the need for proper documentation and set up (Cloudflare Beta), and standardized expectations. You'd be surprised how much website owners complain when things are different, which falls on our shoulders as operators.

              3. website owner level
                When a website owner, as most are, is familiar with basic requirements like staging (a basic need, like water) and backups, that'll restore if a server goes down. The fact I cannot restore a website to any server I want is frightening. You know the core, basic requirements.

              Staging but not staging (needs)
              Backups but not backups (needs)
              But lots and lots of shiny objects (wants)
              Significant difference between needs and wants

              And hell, I'm all for shiny objects. But there is a significant disconnect when I can't onboard clients and scale because basic core requirements are missing, incomplete or non-functional.

              And this isn't even really feedback, I'm just reiterating what I've seen and experienced working with hundreds of hosting companies and thousands upon thousands of website owners. Basically like a food, water, and shelter scenario, the shit we need to survive and scale in the hosting industry.

              Core Requirement

              Priority 10
              Difficulty 1

              Version 1
              Click Create Staging, same server, near-instant

              1. copy database
              2. copy data
              3. update DNS
              4. done, back to work

              Click Push to Live, same server, instant

              1. swap producton and staging domains
              2. no DNS changes
              3. done

              Success Requirements
              Website owners can consistently

              1. create basic staging
              2. push basic staging to production
              3. success

              Version 2
              Shift to new features and cover all of the wants that affect smaller audience segments.

                Adam What some customers have made clear to us is that this doesn't suit their workflow and instead they want the ability to copy the contents (files and database) of a staging website (or even another live website) to an existing live website, overwriting the current data but preserving the source website in place. It's almost a reverse clone. We are working on this feature.

                Adam How do you want to limit it? Do you want functionality similar to CloudFlare zero-trust or do you want to block by IP?

                Most of the other CP have option to configure a login and password for the staging site. Upon connection, a pop-up window will prompt you to enter your credentials. Once entered, you will have public access to the staging site.

                digitalexpanse Documentation has never been Enhance's focus. I'm still awaiting documentation on a manual website recovery from a few months back, specifically when the source server is offline, and we need to restore the website to a new server.

                I'd like to know this too. I've always wondered what to do in case my BM hosting websites fail. Is there a way to restore all backups to a new server?

                digitalexpanse You'd be surprised how much website owners complain when things are different, which falls on our shoulders as operators.

                I completely ignore them now when their disappointment makes no sense. CF integration saves them time and hassle. As for the host, it's fantastic to have access to our client's DNS by impersonating them.

                digitalexpanse Click Create Staging, same server, near-instant

                So you want it on the same server? Why would you like to mix production and staging on the same server?

                            Adrien I'd like to know this too. I've always wondered what to do in case my BM hosting websites fail. Is there a way to restore all backups to a new server?

                            At the moment you have to manually restore the files and databases from the backup server. You will find them in a subdirectory called matching the website ID within your backups mount point.

                            However, the server disaster recovery feature on our roadmap scheduled for May lets you nominate a new server in the UI and automatically restore the websites from backup to that server. This isn't a reversible action so you would only want to do it if the original server is entirely lost.

                            Generally with bare metal servers the provider can swap the disks into a new chassis in the event of a hardware failure which would always be preferable to a restore from backup.

                                Adrien So you want it on the same server? Why would you like to mix production and staging on the same server?

                                I think to enable the domains to be switched without a DNS change. I can see how this would be very useful where the DNS is externally controlled.

                                    Adam I think to enable the domains to be switched without a DNS change. I can see how this would be very useful where the DNS is externally controlled.

                                    Oh got it. Indeed very useful since most of us will have DNS externally controlled (CF or others).

                                      Adam Generally with bare metal servers the provider can swap the disks into a new chassis in the event of a hardware failure which would always be preferable to a restore from backup.

                                      Swapping disks is often a shit show. Today's best practice is to spool up a new, instantly deployable server and get this back online. While the data center resolves the issues with disks or whatever the F is wrong, we'd normally transition back from the temporary deployment.

                                      Server Down, critical issue

                                      1. deploy instant server in 2 minutes, restore, online in 15 minutes
                                      2. beg datacenter to replace, and resolve drive issues, 4hr - 3 days, depending on SLA, plus you still have to restore

                                      Adrien So you want it on the same server? Why would you like to mix production and staging on the same server?

                                      1. ability for an owner to instantly stage
                                      2. ability for the owner to instantly push to live
                                      3. zero network traffic or congestion
                                      4. easy to swap domains
                                      5. website owners screw up a lot (DIYers), easy-to-recreate staging
                                      6. losing website owners that expect this, given how common it is
                                      7. not spending hours internally dealing with this, or educating owners on it

                                      note on network traffic
                                      we use enhance to optimize density, if we're constantly having staging sites flowing at the network level, even in the same data center, its still network congestion that should be available for production traffic

                                      staging sites
                                      on average use zero resources, no traffic to speak of, and owners just trying to manage development and test changes in safe environment, plus are containerized in enhance (safe)

                                      owners expect local staging
                                      I've been doing this 10 years, worked in more hosting dashboards than I can think. I can't recall a single scenario where the owner or I created a staging site and to switch IPs to access their staging site.

                                      We have 1Gb - 125Gb WordPress sites and it's been a shit show dealing with staging so far. And given staging sites have zero traffic, my only concern is storage really. This may be fixable with improved rsync transfers.

                                          Darren thanks, to clarify.
                                          The issue is focused on restoring from manual backups if the primary server is down. Even as it stands now I'm not entirely sure how to restore X websites from backup to a completely new server.

                                          1. do this manually, no clear instructions on how
                                          2. expand the restore option in enhance, allowing me to select any server

                                            I think what you're describing is the disaster recovery option, roadmapped for May.

                                            @Darren @Adam, hopefully, but in the meantime, if a server dies, what's our SOP here to restore websites to an alternate server?

                                            If a server completely died, you could use the existing backups to rsync or scp the backup data over to a new live server (either Enhance or any other panel).

                                            There's no automated tools to do this yet though, that's what the Disaster Recovery feature will enable you to do.

                                            Hello @Darren, @Adam,

                                            What are your thoughts on this staging to production and vice versa thing I have suggested?

                                            I think your idea is good. I think we understand that the staging feature at the moment doesn't really do what is expected of it in terms of the functionality so it is something we will re-visit to work more smoothly and in the way that people intend.

                                            Follow @enhancecp