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


Navigation

    Cloudron Forum

    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular

    Domain Aliases

    Feature Requests
    aliases domains mail
    7
    52
    689
    Loading More Posts
    • 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.
    • girish
      girish Staff @marcusquinn last edited by

      @marcusquinn I tested with EspoCRM portals today and it works well!

      marcusquinn 1 Reply Last reply Reply Quote 2
      • marcusquinn
        marcusquinn @girish last edited by

        @girish Brilliant 🙂 Espo Portals are going to be a game-changer for me, I'm looking at Espo as a rapid web-app development for business, almost can't believe I overlooked it for so long.

        1 Reply Last reply Reply Quote 2
        • Lonk
          Lonk @girish last edited by

          @girish said in Domain Aliases:

          I have checked with WP multisite and it works well (I am sure there are possibly package tweaks we have to do further).

          You da man! This was the big box change to make it all possible. There are some subtle Multisite changes, that I'll submit as PR to WP Developer and WP Managed. They involve:

          1. Upgrading the databases of all subsites on on WP Update (by default, it only upgrades the primary sites database on upgrades and overlooks sub-sites which can cause conflicts) - and this requires only a few WP-CLI lines of code after a WP Update (it detects version changes and upgrades all sub-site databases right away to prevent any sites getting out of sync from the primary sub-site which automatically has it's database upgraded when needed).

          2. The default WP-Cron script included in Cloudron's package runs every minute and disables Wordpress built-in Cron. Sub-sites need to be accounted for when disabling cron, and luckily, I wrote another WP-CLI that loops and runs the Cron Queue for each sub-site (if they exist).

          3. (Optional) I'm writing a "Cloudron for Wordpress" Must Use plugin to make sure if a domain gets changed from within Wordpress, it adds the new domain to the list of aliases in app locations within Cloudron's Dashboard. I see you added an API endpoint for this so it'll be easy enough for me to do, though a user will have to enter in a login token or app token into the WP plugin (UNLESS you'd like to automate this on install).

          girish 1 Reply Last reply Reply Quote 4
          • girish
            girish Staff @Lonk last edited by

            @lonk Sounds great! Let me know if you need help with the WP package changes.

            F 1 Reply Last reply Reply Quote 1
            • F
              freetommy @girish last edited by

              I try to set multisite wordpress.
              but, I can't see aliases/location at wordpress app.
              how or when can I set aliases ?
              Thanks you very much !

              mehdi girish 2 Replies Last reply Reply Quote 0
              • mehdi
                mehdi App Dev @freetommy last edited by

                @freetommy What version is your cloudron ? You must have 6.1.x to be able to use multisite I think

                1 Reply Last reply Reply Quote 1
                • girish
                  girish Staff @freetommy last edited by

                  @freetommy @mehdi While 6.1 adds aliases support, I haven't fixed up the WordPress package yet to have the multiDomain flag. I was waiting for a PR from @Lonk but I think I will go ahead and look into it today 🙂

                  1 Reply Last reply Reply Quote 3
                  • girish
                    girish Staff last edited by

                    The multiste changes are ready. However, I can only publish the app next week. This week there is already an update on WP developer edition pending (the mail plugin was replaced).

                    Initial docs are at https://docs.cloudron.io/apps/wordpress-developer/#multisite . There is also a CLI tool to convert a site to multisite (just adding that to the docs).

                    Lonk 1 Reply Last reply Reply Quote 3
                    • Lonk
                      Lonk @girish last edited by

                      @girish said in Domain Aliases:

                      The multiste changes are ready. However, I can only publish the app next week. This week there is already an update on WP developer edition pending (the mail plugin was replaced).

                      Initial docs are at https://docs.cloudron.io/apps/wordpress-developer/#multisite . There is also a CLI tool to convert a site to multisite (just adding that to the docs).

                      Perfect! As soon as you release this, I'll get to work testing and integrating my multisite quality of life package adjustments and will do a PR for you after I'm finished testing and am satisfied it is ready for production.

                      PS. I've been frequenting this forum less this year than in fall - was there progress with @MooCloud_Matt in regards to repackaging Wordpress for Cloudron using a more efficient stack?

                      girish 1 Reply Last reply Reply Quote 1
                      • girish
                        girish Staff @Lonk last edited by

                        @lonk Yes, thanks! Would love to get it tested first before we announce it to the world 🙂 I will update this post once I publish it, but the changes itself are pushed to https://git.cloudron.io/cloudron/wordpress-developer-app/ if you want to build it on your own.

                        For the more efficient stack, what I have seen is installing some file cache for pages like WP Total Cache totally boosts performance numbers. I am wondering if we should just install this by default.

                        marcusquinn Lonk 2 Replies Last reply Reply Quote 0
                        • marcusquinn
                          marcusquinn @girish last edited by

                          @girish If you were going to make anything default, it ought to be the officially supported WP Super Cache.

                          Despite it having a lesser review rating on wordpress.org because they're not actively soliciting positive reviews and targeting negative ones for removal or improvement because it's not commercial. We tried all of them and WP Super Cache was the best results, flexibility, only one supporting fragment caching, lots of hooks and good code quality.

                          girish 1 Reply Last reply Reply Quote 0
                          • girish
                            girish Staff @marcusquinn last edited by

                            @marcusquinn said in Domain Aliases:

                            WP Super Cache

                            https://wordpress.org/plugins/wp-super-cache/ right? The one developed by automatic.

                            d19dotca marcusquinn 2 Replies Last reply Reply Quote 1
                            • d19dotca
                              d19dotca @girish last edited by

                              @girish For what it's worth, caching tools tend to be personal preference, so I'd refrain from making anything default in there if it were me making that decision, and maybe just include some general performance recommendations in the docs instead.

                              marcusquinn 1 Reply Last reply Reply Quote 0
                              • marcusquinn
                                marcusquinn @girish last edited by

                                @girish Yup, I don't think you can go wrong with the official one, it's as good as core and what they use on wordpress.com

                                1 Reply Last reply Reply Quote 0
                                • marcusquinn
                                  marcusquinn @d19dotca last edited by marcusquinn

                                  @d19dotca 🙂 In my experience they tend to be more marketing and reviews bias preferences because the paid-pro versions afford to play to that game. I can only share what we went through testing them all and coming to conclusions.

                                  I also know that they can cause a lot of problems in hiding underlying inefficiencies, creating their own bugs, interfering with debugging.

                                  Add in dynamic content and there really are no other options that will do fragment caching, so you either have full-page caching and no dynamic content or no caching and all the inefficiencies come back to haunt as soon as a user logs in and everything's uncacheable because one tiny part of a page is dynamic.

                                  Granted, most Wordpress websites don't have Woocommerce or other functional features, but as people discover and add them, then then you have to come back to explain their caching plugin doesn't help for dynamic content and the whole stack needs revisiting.

                                  I guess it comes down to what compelling difference would make one trust Automattic's core platform but not their caching methodology?

                                  d19dotca 1 Reply Last reply Reply Quote 1
                                  • Lonk
                                    Lonk @girish last edited by

                                    @girish said in Domain Aliases:

                                    For the more efficient stack, what I have seen is installing some file cache for pages like WP Total Cache totally boosts performance numbers. I am wondering if we should just install this by default.

                                    Personally, I have no issues with the current stack (even without the caching plugin, honestly, REDIS is enough for me). I just know you were working with @MooCloud_Matt in revising the stack and since I've been gone for a bit, I wasn't sure if you guys ever came to any solid conclusions in his "Wordpress Stack Comparison" thread.

                                    1 Reply Last reply Reply Quote 1
                                    • d19dotca
                                      d19dotca @marcusquinn last edited by d19dotca

                                      @marcusquinn I agree to most of what you wrote. But just to be clear... my comment wasn't meant to be taken as to why one would or wouldn't trust Automattic's caching functionality, in fact it wasn't really meant to be about caching at all (though I admittedly didn't clarify that at all in my comment haha, my bad).

                                      I fundamentally believe that we should strive to stay away from any kind of "bloat" and keeping it to only required plugins in the app package. This is for a few reasons (of course these are just my own opinions):

                                      1. The WordPress Dev app package should ideally be as close as possible to a default WordPress.org install in a LAMP server.
                                      2. The only plugins that should be included OOTB should be for fundamental requirements such as the SMTP plugin for sending emails.
                                      3. Any plugins that aren't requirements for WordPress to function OOTB, should not be included. This keeps the app package lean, and prevents plugin "bloat".
                                      4. Where do we draw the line of which plugins should be included and which should not? I think it's a fine line, and in my opinion should be placed right between "required" plugins and "nice-to-have" plugins. Maybe some disagree but I personally see caching plugins as "nice-to-have". There's a reason they aren't included OOTB in any WordPress installs.
                                      5. Caching plugins in particular have a history of causing unintended side effects, as you alluded to as well. And while you and I may already understand those side effects and know how to work around them, not everyone deploying WordPress will understand that and will inevitably run into issues between what they see in the backend vs frontend and not understanding why it's behaving that way, etc. To be fair, I suspect most people running the WordPress Developer edition will already be well aware of that whole dynamic, but not everyone will be.

                                      I just fundamentally believe that the WordPress app package should only include required functionality, no nice-to-haves no matter how many people end up installing the nice-to-have plugins anyways. I think going down the route of including caching plugins (or other nice-to-have plugins) is the wrong route to take for the longevity of this app package.

                                      Hopefully that makes sense. 🙂

                                      marcusquinn 1 Reply Last reply Reply Quote 3
                                      • marcusquinn
                                        marcusquinn @d19dotca last edited by

                                        @d19dotca I'm inclined to agree that it might be something better documented - but more-so because caching problems can cause support burdens where they are a common source of issue for the uninitiated.

                                        I like your suggestion that documentations have comments like "we tested this and it worked for us" sort of thing.

                                        1 Reply Last reply Reply Quote 2
                                        • marcusquinn
                                          marcusquinn last edited by

                                          Anyone know/tested if domain aliases work for email addresses too/yet?

                                          girish 1 Reply Last reply Reply Quote 0
                                          • girish
                                            girish Staff @marcusquinn last edited by

                                            @marcusquinn they don't , no.

                                            1 Reply Last reply Reply Quote 1
                                            • First post
                                              Last post