Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.


Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Bookmarks
  • Search
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo

Cloudron Forum

Apps | Demo | Docs | Install
  1. Cloudron Forum
  2. WordPress (Developer)
  3. Changed WP URL From within WP -- Site Can't be Found

Changed WP URL From within WP -- Site Can't be Found

Scheduled Pinned Locked Moved Solved WordPress (Developer)
9 Posts 3 Posters 1.2k Views 3 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • S Offline
    S Offline
    Shaun Snapp
    wrote on last edited by
    #1

    Hello,

    I changed the URL from within the WP dashboard. What I did not realize is that this is done within the Cloudron app configuration. I tested changing it there on a 2nd WP instance and it worked fine.

    However, the 1st WP instance, where I changed it incorrectly, is not reachable through the admin panel. I have the A record created at my domain registrar correctly. And I also tried to reapply a name change through Cloudron for this 1st WP instance (hoping it would overwrite the setting in the WP admin panel, but it is not taking. It is also not responding to trying to force the URL change through the wp.config.php file.

    Do you have any idea how I can recover this instance? It appears that WP is stuck and has a conflict with Cloudron.

    LonkleL 1 Reply Last reply
    0
    • girishG Offline
      girishG Offline
      girish
      Staff
      wrote on last edited by
      #2

      @Shaun-Snapp Usually, a restart of the app will "sync" up the site url inside WordPress and the one configured in Cloudron. You can restart from the Console section of the app.

      When you say it is unreachable, do you mean you see a Cloudron 404 page (nginx) or the browser gives some DNS error?

      S 1 Reply Last reply
      1
      • S Shaun Snapp

        Hello,

        I changed the URL from within the WP dashboard. What I did not realize is that this is done within the Cloudron app configuration. I tested changing it there on a 2nd WP instance and it worked fine.

        However, the 1st WP instance, where I changed it incorrectly, is not reachable through the admin panel. I have the A record created at my domain registrar correctly. And I also tried to reapply a name change through Cloudron for this 1st WP instance (hoping it would overwrite the setting in the WP admin panel, but it is not taking. It is also not responding to trying to force the URL change through the wp.config.php file.

        Do you have any idea how I can recover this instance? It appears that WP is stuck and has a conflict with Cloudron.

        LonkleL Offline
        LonkleL Offline
        Lonkle
        wrote on last edited by
        #3

        @Shaun-Snapp Don't worry, in the worst of case, you can access the DB with a Remote SQL app and change the values yourself, I had to do that once in a multisite installation (which Cloudron doesn't support changing the domain of - yet). Let us know if restarting the app reconfigures the domain and if not, we'll go to next steps.

        S 1 Reply Last reply
        1
        • LonkleL Lonkle

          @Shaun-Snapp Don't worry, in the worst of case, you can access the DB with a Remote SQL app and change the values yourself, I had to do that once in a multisite installation (which Cloudron doesn't support changing the domain of - yet). Let us know if restarting the app reconfigures the domain and if not, we'll go to next steps.

          S Offline
          S Offline
          Shaun Snapp
          wrote on last edited by
          #4

          @Lonk Thanks. I tried the remove SQL approach, but failed.

          I did restart the app. But I tried it again just to make sure I covered that base. But it did not bring it back. It is still not responding.

          1 Reply Last reply
          0
          • girishG girish

            @Shaun-Snapp Usually, a restart of the app will "sync" up the site url inside WordPress and the one configured in Cloudron. You can restart from the Console section of the app.

            When you say it is unreachable, do you mean you see a Cloudron 404 page (nginx) or the browser gives some DNS error?

            S Offline
            S Offline
            Shaun Snapp
            wrote on last edited by
            #5

            @girish I did see the 404 page before, but after restarting, and also changing the URL back to what it was through the Cloudron UI, I see the 502 Bad Gateway error.

            1 Reply Last reply
            0
            • girishG Offline
              girishG Offline
              girish
              Staff
              wrote on last edited by
              #6

              @Shaun-Snapp Usually, if it's a 5xx error, you will see some error in the app logs. Console -> Logs. Anything interesting there?

              S 1 Reply Last reply
              0
              • girishG girish

                @Shaun-Snapp Usually, if it's a 5xx error, you will see some error in the app logs. Console -> Logs. Anything interesting there?

                S Offline
                S Offline
                Shaun Snapp
                wrote on last edited by
                #7

                @girish This is the information after the backup yesterday, and when the problem started.

                Oct 05 23:00:04 backing up
                Oct 05 23:00:04 217:M 06 Oct 06:00:04.479 * DB saved on disk
                Oct 06 09:58:07 2020-10-06 16:58:07,653 WARN received SIGTERM indicating exit request
                Oct 06 09:58:07 2020-10-06 16:58:07,653 INFO waiting for redis, redis-service to die
                Oct 06 09:58:07 2020-10-06 16:58:07,654 INFO stopped: redis-service (terminated by SIGTERM)
                Oct 06 09:58:07 217:signal-handler (1602003487) Received SIGTERM scheduling shutdown...
                Oct 06 09:58:07 217:M 06 Oct 16:58:07.659 # User requested shutdown...
                Oct 06 09:58:07 217:M 06 Oct 16:58:07.659 * Saving the final RDB snapshot before exiting.
                Oct 06 09:58:07 217:M 06 Oct 16:58:07.660 * DB saved on disk
                Oct 06 09:58:07 217:M 06 Oct 16:58:07.660 * Removing the pid file.
                Oct 06 09:58:07 217:M 06 Oct 16:58:07.660 # Redis is now ready to exit, bye bye...
                Oct 06 09:58:07 2020-10-06 16:58:07,660 INFO stopped: redis (exit status 0)
                Oct 06 10:01:10 Generating SSL certificate
                Oct 06 10:01:10 Generating a RSA private key
                Oct 06 10:01:10 ........+++++
                Oct 06 10:01:10 ............+++++
                Oct 06 10:01:10 writing new private key to '/run/redis.cloudron.key'
                Oct 06 10:01:10 -----
                Oct 06 10:01:10 Starting supervisor
                Oct 06 10:01:10 2020-10-06 17:01:10,173 CRIT Supervisor running as root (no user in config file)
                Oct 06 10:01:10 2020-10-06 17:01:10,173 INFO Included extra file "/etc/supervisor/conf.d/redis-service.conf" during parsing
                Oct 06 10:01:10 2020-10-06 17:01:10,173 INFO Included extra file "/etc/supervisor/conf.d/redis.conf" during parsing
                Oct 06 10:01:10 2020-10-06 17:01:10,180 INFO RPC interface 'supervisor' initialized
                Oct 06 10:01:10 2020-10-06 17:01:10,180 CRIT Server 'inet_http_server' running without any HTTP authentication checking
                Oct 06 10:01:10 2020-10-06 17:01:10,180 INFO RPC interface 'supervisor' initialized
                Oct 06 10:01:10 2020-10-06 17:01:10,180 CRIT Server 'unix_http_server' running without any HTTP authentication checking
                Oct 06 10:01:10 2020-10-06 17:01:10,180 INFO supervisord started with pid 1
                Oct 06 10:01:11 2020-10-06 17:01:11,184 INFO spawned: 'redis' with pid 15
                Oct 06 10:01:11 2020-10-06 17:01:11,187 INFO spawned: 'redis-service' with pid 16
                Oct 06 10:01:11 15:C 06 Oct 17:01:11.195 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
                Oct 06 10:01:11 15:C 06 Oct 17:01:11.195 # Redis version=4.0.9, bits=64, commit=00000000, modified=0, pid=15, just started
                Oct 06 10:01:11 15:C 06 Oct 17:01:11.195 # Configuration loaded
                Oct 06 10:01:11 15:M 06 Oct 17:01:11.196 * Running mode=standalone, port=6379.
                Oct 06 10:01:11 15:M 06 Oct 17:01:11.196 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
                Oct 06 10:01:11 15:M 06 Oct 17:01:11.196 # Server initialized
                Oct 06 10:01:11 15:M 06 Oct 17:01:11.196 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
                Oct 06 10:01:11 15:M 06 Oct 17:01:11.196 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.
                Oct 06 10:01:11 15:M 06 Oct 17:01:11.197 * DB loaded from disk: 0.000 seconds
                Oct 06 10:01:11 15:M 06 Oct 17:01:11.197 * Ready to accept connections
                Oct 06 10:01:11 Redis service endpoint listening on https://:::3000
                Oct 06 10:01:12 2020-10-06 17:01:12,288 INFO success: redis entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
                Oct 06 10:01:12 2020-10-06 17:01:12,288 INFO success: redis-service entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

                1 Reply Last reply
                0
                • girishG Offline
                  girishG Offline
                  girish
                  Staff
                  wrote on last edited by
                  #8

                  What's strange is that the app doesn't seem to be running at all since there is no health check going on. Usually otherwise there is a CloudronHealthCheck in the logs every 10 seconds. Is the app stopped or in repair mode by any chance?

                  @Shaun-Snapp Are you able to enable to enable remote access (Support -> Enable SSH) and reach out to me on support@cloudron.io ? I can take a look immediately.

                  1 Reply Last reply
                  0
                  • S Offline
                    S Offline
                    Shaun Snapp
                    wrote on last edited by
                    #9

                    My error. I had the site stuck in recovery mode. It is back up now.

                    I am back to normal. Thanks

                    1 Reply Last reply
                    2
                    Reply
                    • Reply as topic
                    Log in to reply
                    • Oldest to Newest
                    • Newest to Oldest
                    • Most Votes


                    • Login

                    • Don't have an account? Register

                    • Login or register to search.
                    • First post
                      Last post
                    0
                    • Categories
                    • Recent
                    • Tags
                    • Popular
                    • Bookmarks
                    • Search