The 2.x branch of subdomain was described as a simplification. I'm all for simplifying code, but not for removing essential functionality. The beauty of subdomain's use of the path module is that path is compatible with everything -- nodes, views, taxonomy, blocks, rules, panels -- everything. Adding subdomains to path aliases was a powerful combination capable of producing almost any result -- with fine-grained manual control, as well as many options for automation.

  • Place any node, view, panel, taxonomy term, or any other page on subdomain foo just by adding "~foo" to the path alias
  • Blocks can appear on subdomains using the same methods: add "~foo*" to the block visibility field to have it show up on the foo subdomain, add "~foo/mypage/etc." for a specific page or section within a subdomain, or you can even add "~*" to make a block show up on every subdomain.
  • Simple and flexible automation using pathauto: place "~foo" or "~bar" etc. before any pathauto entry to automatically place content on subdomains
  • For even better control over automation, the rules module could be used to place content on subdomains by taking any combination of fields, taxonomies, author attributes (like the author's user role), and using branching logic to decide what subdomain to use, then update the path alias accordingly.
  • The module also generated a [subdomain] token for use in pathauto, although it wasn't nearly as useful as the above methods

The 2.x version, by removing support for the path module, reduces this module from incredibly powerful, to almost useless. All fine-grained manual control of subdomains is now gone, block support is gone, views, panels, etc. no longer work on subdomains, rules integration no longer works. All that's left are a couple of the auto-generated subdomain options, which weren't very useful in the first place.
What's needed is to scrap this 2.x branch, and instead focus on porting the far better 1.7 version to D7 so that we can continue taking advantage of its powerful features to create great websites.

Comments

zazinteractive’s picture

zazinteractive commented

I agree. The ~ custom subdomains are the best part

savioret’s picture

savioret commented

I agree too.
I'm in the middle of the process of migrating my site to drupal 7.
I found that there is no 6.x-1.x upgrade to drupal 7 and the 2.x current branch completely broke my site.

This was a bad decision from the maintainers.
I was so happy with this module that I made a donation when the button was still in the project page...
I want my donation back ! XDD

I think I'll try to make my own port to drupal 7

honza pobořil’s picture

honza pobořil commented

Why not implement this features to 7.x-2.x version? It should not be so hard. I think it is much reasonable than making own port of old version.

savioret’s picture

savioret commented

Bobik,

If you read the new branch code you'll see that they have chosen a completely different philosophy of doing the things. There's no way back.
Now everything is simpler for the user (thus less flexible).
Now there are no dependencies with pathauto. You don't have to worry about how to generate your aliases, as the new version decides that for you (here resides de main problem).

I have been working in a port of the 1.x branch to Drupal 7.
It is working for me. I have only tested it for "User" sudomain type, and it works exactly as in version 6.x-1.x using the tilde character, and the token [subdomain] for pathauto aliases.

As the module has a GPL License I'm thinking of uploading it to bitbucket or creating a new project as a fork of this, the only problem is that I don't know how much time I'll have to dedicate to it.

I can send you a copy if you wish.

honza pobořil’s picture

honza pobořil commented

It is great you want to do it different way. I am new between maintainers and my mission is only to keep going some important issues, but I don't know this module so much.

I think it is the best to keep development on this project. I understand difference between more flexible or more ready to use way. If it is possible I vote for divide this two mindsets into two branches and for some time maintain both.

What do you think?
What branch name to use?
(sending link to "old" developers too)

rwohleb’s picture

rwohleb
he/him
Primary language English
commented
Version: 6.x-2.x-dev » 7.x-2.x-dev
Status: Active » Postponed (maintainer needs more info)

There were MANY issues with how the 1.x code was structured. The flexibility that some of you are claiming came at the cost of security and maintainability. The old 6.x-1.x branch didn't have a record of which subdomains existed, and was severely limited by what the pathauto module supported. None of the maintainers saw your usage model as a good idea, so none of us took it into account when we rewrote it.

The new system is extremely flexible and deterministic. I don't believe anything in the 7.x-2.x branch precludes you from doing what you want to do. In fact, the new design is built to encapsulate each mode in a class such that we only have to add new classes for new modes. All you have to do is supply a patch.

If you fork the code without first attempting to work with the maintainers, it's generally considered bad form and frowned upon in the Drupal community. I don't believe any of us have said we wouldn't accept something from any of you for this. If you fork the 7.x-2.x branch into a sandbox and make your changes there, I'm sure at least one of us would be happy to take a look and give you feedback so that it could eventually be merged into this project.

colemanw’s picture

colemanw commented

For the record, I've learned a lot about Drupal best-practices in the 4 years since I created this issue.

I think the bottom line is that using this module to create "fake" subdomains for your site (e.g. putting all blog content on blog.mysite.com) is not a great idea. Drupal was never intended to do something like that, so you will always be swimming against the current; ajax callbacks might fail, redirects may not work, https can cause problems, and some modules just won't work in this kind of setup.

Drupal was intended to do multisites using "real" subdomains, so I recommend a true multisite setup for anyone who really needs subdomains. And for those of you who don't really need them but just want blog.mysite.com for the sake of vanity - dude, get over it and settle for mysite.com/blog instead - no one but you really cares what your url looks like :P

savioret’s picture

savioret commented

rwohleb,

The main reason for my "complaint" is that at the current point of my Drupal upgrading process I'm stuck.
I have found that I am not able to achieve what I was able to do before, my current functionality is broken.
I have around 70 3rd party modules in my site, and this is the only one that upgrading it didn't allow me to keep things as before.
After upgrading some modules, I've found issues where I've been forced to change the way of doing the things, but there was always a way to do what I was doing in version 6.

Let me explain my situation, in my case I just generate subdomains for the main user profile page, and the user gallery, this is :

domain.com/user/1  --> username.domain.com
domain.com/user/1/gallery  --> username.domain.com/gallery

That's it. But the new version forces me to generate subdomains for all content user.
I just need to keep redirecting these two routes, not all user-related.

Maybe I can achieve this using branch 7.x-2.x, but I didn't find the way to do it.
If there's such way, I'd be pleased if you could explain it, please.

The reason of porting the 6.x-1.x branch to drupal 7 was because of my need of keeping my current site subdomain behavior.
My idea was to keep it in private, as it was a quick one-day port, probably buggy, but I thought that it could be useful for someone in my same situation, and may help testing it.

But I repeat, I would prefer using 7.x-2.x if I could do what I described above.

Thank you for helping.

rwohleb’s picture

rwohleb
he/him
Primary language English
commented

@savioret, I see two issues that need to be solved to fix your situation. First, are there any special things you are doing to select the user's subdomain (ie. a prefix), or are they just a cleaned version of the username? If they are just the username, then you may be good on that front. We may have to look at adding a compatibility mode so that the names we generate are the same as those pathauto would generate.

Second, we could look at adding whitelisting and blacklisting capabilities to the code. This way you could include/exclude certain paths from being assigned to a a subdomain. This should solve your issue of only having a couple of things on the user subdomain.

We should at least add some new hooks that allow developers to modify which domain a piece of content is assigned to. We could then keep the whitelisting/blacklisting in an add-on module since it would add extra overhead to content lookups.

savioret’s picture

savioret commented

Hello @rwohleb

Sorry for the late reply.
I think that whitelisting would be the best solution in my case as I only need to subdomain 2 user paths.
Complemented with a a blacklisting feature may be a great solution for all users that need to upgrade from the previous branch.

I don't think that a new module would be necessary, assuming that there's a textarea and a switch of white or black listing (similar as the visualization options of a block), the value of this can be stored as a Drupal global variable as it will usually be compound of just a few urls.
Thus, the need of the lookup would just be checking is the variable is not empty.

savioret’s picture

savioret commented

Hi
Is there any update on this ?
The whitelisting would be great if implemented.

I finally finished my whole site upgrade a month ago, I had to make use of my own Subdomain D6 version ported to D7, and it's working fine for now.
I know this is not the way to go, however I had no option :-(

rwohleb’s picture

rwohleb
he/him
Primary language English
commented

Sorry, no update at present. Unfortunately I haven't had any time to work on issues lately. I'm glad you have a solution in the interim. Please keep following this issue in case I somehow find more hours in a day ;)