New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Splitting YOURLS_SITE - Added Features #2335

Open
PopVeKind opened this Issue Dec 8, 2017 · 8 comments

Comments

Projects
None yet
2 participants
@PopVeKind
Contributor

PopVeKind commented Dec 8, 2017

YOURLS Community Benefits

The following are possible YOURLS Community Benefits that will be available by adopting this little patch.

This Patch (GitHub Branch multisite) does nothing by itself! As Ozh has said before, "Then let's add what's needed to make it possible to implement this feature as a plugin :)" In fact, this one small patch will allow many features to be added as plugins (see list below). My former patches were focused on adding features that I and others wanted. After an exhaustive search of issues and PR's, this patch is a complete departure from that frame of mind. The focus of this patch is "what changes would be necessary and required to create a MultiSite Plugin feature?"

This patch is centered around Splitting YOURLS_SITE.

This patch will reduce or eliminate many support requests concerning YOURLS_SITE because it is automatically calculated. The patch is absolutely required for any MultiSite development. Without Splitting YOURLS_SITE, the most commonly requested features cannot be developed (see Plugins in the list below).

Search the issues for any defined constant and it is obvious that the syntax and usage of YOURLS_SITE have more discussion, more misconfiguration, more confusion for the average user, and more support requests than any other. This patch suggests YOURLS_SITE be removed from config-sample.php to "Prevent Noob Confusion!"

Search the PR's for YOURLS_SITE and it quickly stands out that many PR's for additional features (see Plugins listed below), all depend on splitting YOURLS_SITE. These PR's are rejected because they add an option or setting to the config file - that every site admin must add (even more misconfiguration, more confusion for the average user, and more support requests!). This patch calculates everything automatically, for "Less Noob Confusion" and fewer support requests.

List of Benefits

Even in a Single Site mode, this patch may benefit the YOURLS community in the following ways:

  1. YOURLS_SITE is automatically calculated in most cases (less noob confusion for the average user).
  2. 100% Drop-in Compatible with all standard installed YOURLS sites.
  3. Prevents Code Bloat by moving feature code into plugins
  4. MultiSite Plugin (one install to manage several domains) - A Roadmap planned feature.
  5. WordPress Plus YOURLS Plugin - working together without conflict in the document root directory.
  6. Gives YOURLS its own directory Plugin
  7. Rename the admin directory Plugin
  8. Admin Diag Page Plugin (Noob Friendly!)
    Adds a diagnostic page to the admin area
    Helps fix the trailing edge slash configuration error
    Provides technical details regarding the environment to copy/paste into issues
    Tests config options and reveals common errors
    Offers easy advice on fixing noob errors
    Gives advice on best practices, like how to convert from a single site to Multisite.
  9. Load Balancer / Reverse Proxy Plugin Allows YOURLS to function in HTTPS behind Load Balancers and Reverse Proxies of various types (stand-alone, "Black Boxes", ISS, Nginx, Apache, and others).
  10. Promotes Standardized Server Configuration Files using the copy/paste/modify method that is easily used by noobs. For example, there is only one copy/paste .htaccess file for ALL sites (both document root and subdomain sites). Currently, there are two different .htaccess files (one for a document root site and a different one for a subdomain site.
  11. Future Enhanced Performance - Paves the way for enhanced performance and reduce bloat. There are a number of code blocks and functions that could be made more efficient, or totally eliminated, by incorporating constructs made available in this patch.
  12. Renames the config.php file to [domain-name]-config.php (sho.rt-config.php) this allows MultiSite to respond differently (different config files) based on domain name. For legacy support (backward compatible single site), config.php is also accepted.

GitHub Branch multisite.

NOTE: At first I considered function yourls_site_url() as a possible solution. That resulted in a dirty method that gets really messy, really fast. It is far easier to detect or calculate what the Absolute URL is and use that to define a YOURLS_ABSURL constant. Then replace a small amount of YOURLS_SITE with YOURLS_ABSURL in the few places that need it. Far cleaner code. The same is true for the admin protocol. It is better and cleaner to detect the admin protocol and use that, rather than to define YOURLS_SITE and then redefine (change) the protocol with YOURLS_ADMIN_SSL. I would suggest using simple server settings to prevent HTTP requests in the admin area if desired. Then detect and use the protocol from the http request headers. YOURLS_ADMIN_SSL is not needed. Far easier, more secure, simpler and less code I may work on that clean up after I finish with multisite.

@majordome

This comment has been minimized.

Show comment
Hide comment
@majordome

majordome bot Dec 8, 2017

Hey @PopVeKind, thanks for opening an issue!

Your reply is very long.
As a bot, I take less than a second to read it but summing it up a little bit will help old-fashioned humans understand your thought.

majordome bot commented Dec 8, 2017

Hey @PopVeKind, thanks for opening an issue!

Your reply is very long.
As a bot, I take less than a second to read it but summing it up a little bit will help old-fashioned humans understand your thought.

@PopVeKind

This comment has been minimized.

Show comment
Hide comment
@PopVeKind

PopVeKind Dec 8, 2017

Contributor

This small patch automatically creates a constant YOURLS_ABSURL the Absolute URL where the YOURLS Files are. This replaces one purpose of YOURLS_SITE (the other purpose is to create shortened URLs), and it allows them to have different values.

This is required for multisite and for many other features proposed over the last five years and rejected for adding complexity to the config file. This patch actually reduces complexity.

Contributor

PopVeKind commented Dec 8, 2017

This small patch automatically creates a constant YOURLS_ABSURL the Absolute URL where the YOURLS Files are. This replaces one purpose of YOURLS_SITE (the other purpose is to create shortened URLs), and it allows them to have different values.

This is required for multisite and for many other features proposed over the last five years and rejected for adding complexity to the config file. This patch actually reduces complexity.

@dgw

This comment has been minimized.

Show comment
Hide comment
@dgw

dgw Dec 9, 2017

Collaborator

This patch does…

What patch? This is an issue, there's no diff attached.

Collaborator

dgw commented Dec 9, 2017

This patch does…

What patch? This is an issue, there's no diff attached.

PopVeKind referenced this issue in PopVeKind/YOURLS Dec 9, 2017

MultiSite - Split YOURLS-SITE + Autodetect - Add MultiSite Config Files
This Patch Prepares the way for true MultiSite.  It automatically defines
1. YOURLS_SITE (used to make shortened URLs) and
2. YOURLS_ABSURL (the Absolute URL for the site files).
3. Plus it adds MultiSite Config.
@PopVeKind

This comment has been minimized.

Show comment
Hide comment
@PopVeKind

PopVeKind Dec 9, 2017

Contributor

@dgw - Please see this patch Difference attached at GitHub - Click Here.

The link to the GitHub multisite branch (the patch) was listed in the first post. Click Here

Oops, sorry. I am trying to understand the rules here. It says to talk about changes first - before submitting a Pull Request. I am trying to comply.

I am also new to GitHub. As they say, still on the learning curve, and would appreciate any helpful suggestions. Likewise, the Philippines has the slowest, most costly Internet in Asia, so I can only upload files during certain times of the day.

Contributor

PopVeKind commented Dec 9, 2017

@dgw - Please see this patch Difference attached at GitHub - Click Here.

The link to the GitHub multisite branch (the patch) was listed in the first post. Click Here

Oops, sorry. I am trying to understand the rules here. It says to talk about changes first - before submitting a Pull Request. I am trying to comply.

I am also new to GitHub. As they say, still on the learning curve, and would appreciate any helpful suggestions. Likewise, the Philippines has the slowest, most costly Internet in Asia, so I can only upload files during certain times of the day.

@dgw

This comment has been minimized.

Show comment
Hide comment
@dgw

dgw Dec 9, 2017

Collaborator

@PopVeKind Discussing changes before opening a pull request is fine, but if you're talking about a patch that's already written it's certainly fine to at least link to it from the discussion.

That would probably help a lot with trimming down the length of your comments, as well. Let the code speak for itself sometimes, and you'll get fewer "very long" auto-replies from @majordome.

I actually admire how in-depth and detailed your issue comments are. But I also must admit, a lot of the time I just skim them because they are often so overwhelmingly long that actually reading the whole thing (especially on mobile) becomes daunting. That said, brevity is a learned skill too, just like using git or GitHub. Sometimes I catch myself getting rather long-winded on proposed changes too. :)

Collaborator

dgw commented Dec 9, 2017

@PopVeKind Discussing changes before opening a pull request is fine, but if you're talking about a patch that's already written it's certainly fine to at least link to it from the discussion.

That would probably help a lot with trimming down the length of your comments, as well. Let the code speak for itself sometimes, and you'll get fewer "very long" auto-replies from @majordome.

I actually admire how in-depth and detailed your issue comments are. But I also must admit, a lot of the time I just skim them because they are often so overwhelmingly long that actually reading the whole thing (especially on mobile) becomes daunting. That said, brevity is a learned skill too, just like using git or GitHub. Sometimes I catch myself getting rather long-winded on proposed changes too. :)

@PopVeKind

This comment has been minimized.

Show comment
Hide comment
@PopVeKind

PopVeKind Dec 10, 2017

Contributor

@dgw - Thank You for your advice, I am trying to adapt.

On the first post. near the bottom, I wrote "GitHub Branch multisite." This is a link to the patch code. I am sure you missed it. Would you help me improve this?

  • Should I have put this link at the top?
  • Will you suggest a more approved wording for this link?

I have been making a serious attempt to learn the skill of brevity so that @majordome won't complain. For more than 50+ years I worked in government and huge organization shops with high security, where every little thing had to be documented. It is actually daunting to go from that to OpenSource and GitHub. However, I am determined to adapt.

Contributor

PopVeKind commented Dec 10, 2017

@dgw - Thank You for your advice, I am trying to adapt.

On the first post. near the bottom, I wrote "GitHub Branch multisite." This is a link to the patch code. I am sure you missed it. Would you help me improve this?

  • Should I have put this link at the top?
  • Will you suggest a more approved wording for this link?

I have been making a serious attempt to learn the skill of brevity so that @majordome won't complain. For more than 50+ years I worked in government and huge organization shops with high security, where every little thing had to be documented. It is actually daunting to go from that to OpenSource and GitHub. However, I am determined to adapt.

@dgw

This comment has been minimized.

Show comment
Hide comment
@dgw

dgw Dec 10, 2017

Collaborator

@PopVeKind Yes, I really did miss the link. Not sure if it was because I read the original comment in an email before the link was edited in (which doesn't send a notification) or something like that, but it is pretty inconspicuous.

Putting the link at the top would be a huge step, I think. As far as the wording goes, you actually had a perfect place to insert the link near the top: the words "this little patch" in the first paragraph.

Having every little thing documented is the ideal state of open source projects, in my opinion, but the majority of them simply never reach the ideal standard for any of a number of reasons. Developers focus on other things, or don't know how to do that kind of meticulous documentation, or simply lose track of the process and forget to keep it up, or, or, or… But that's why I really admire your attention to detail. It's somewhat rare, in my (not extremely long) experience with OSS projects, and the broader software development community would be better off if more developers had your experience and dedication in that area. Or, if they had time to exercise it—frankly, a big part of why your level of detail is so uncommon comes down to the sheer number of developers who do this stuff in their spare time and can't afford to spend upwards of half an hour compiling each comment.

(Now, real irony would be if this comment trips a warning to me from @majordome. I don't know the threshold off the top of my head. 😂)

Collaborator

dgw commented Dec 10, 2017

@PopVeKind Yes, I really did miss the link. Not sure if it was because I read the original comment in an email before the link was edited in (which doesn't send a notification) or something like that, but it is pretty inconspicuous.

Putting the link at the top would be a huge step, I think. As far as the wording goes, you actually had a perfect place to insert the link near the top: the words "this little patch" in the first paragraph.

Having every little thing documented is the ideal state of open source projects, in my opinion, but the majority of them simply never reach the ideal standard for any of a number of reasons. Developers focus on other things, or don't know how to do that kind of meticulous documentation, or simply lose track of the process and forget to keep it up, or, or, or… But that's why I really admire your attention to detail. It's somewhat rare, in my (not extremely long) experience with OSS projects, and the broader software development community would be better off if more developers had your experience and dedication in that area. Or, if they had time to exercise it—frankly, a big part of why your level of detail is so uncommon comes down to the sheer number of developers who do this stuff in their spare time and can't afford to spend upwards of half an hour compiling each comment.

(Now, real irony would be if this comment trips a warning to me from @majordome. I don't know the threshold off the top of my head. 😂)

@PopVeKind

This comment has been minimized.

Show comment
Hide comment
@PopVeKind

PopVeKind Dec 11, 2017

Contributor

@dgw - I didn't know you can edit like that until right now! lol So much to learn!

Where I'm from every little thing is logged automatically, and everybody knows it. We were only allowed to edit a post for 20 minutes. After that, only to change spelling errors, typos, and really stupid code errors!

Well, I used my newfound superpower to add the link to the top, for any others who may follow.

The real irony is that I went from 50+ years in a place where I was forced to document everything, to a place where I have the time to do it! The only other thing I have to do is think about my 23 grandchildren and my great-grandson! :)

If you try this patch (even on a test server), will you let me know what you think? I currently have a prototype for the MultiSite Plugin server setup. Six different domain names running on one copy of YOURLS. This is Running on Apache (HTTP).

In a week or two I hope to have a Linode I can run in https on Nginx. I will put three production site there with:

  • WordPress MultiSite
  • YOURLS MultiSite
  • MultiSite Plugin
  • WordPress Plus YOURLS Plugin
  • Rename the admin directory Plugin
  • Three Domains
  • All addressed in the document root directory.

Fun!

Contributor

PopVeKind commented Dec 11, 2017

@dgw - I didn't know you can edit like that until right now! lol So much to learn!

Where I'm from every little thing is logged automatically, and everybody knows it. We were only allowed to edit a post for 20 minutes. After that, only to change spelling errors, typos, and really stupid code errors!

Well, I used my newfound superpower to add the link to the top, for any others who may follow.

The real irony is that I went from 50+ years in a place where I was forced to document everything, to a place where I have the time to do it! The only other thing I have to do is think about my 23 grandchildren and my great-grandson! :)

If you try this patch (even on a test server), will you let me know what you think? I currently have a prototype for the MultiSite Plugin server setup. Six different domain names running on one copy of YOURLS. This is Running on Apache (HTTP).

In a week or two I hope to have a Linode I can run in https on Nginx. I will put three production site there with:

  • WordPress MultiSite
  • YOURLS MultiSite
  • MultiSite Plugin
  • WordPress Plus YOURLS Plugin
  • Rename the admin directory Plugin
  • Three Domains
  • All addressed in the document root directory.

Fun!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment