ExpressionEngine CMS
Open, Free, Amazing

Thread

This is an archived forum and the content is probably no longer relevant, but is provided here for posterity.

The active forums are here.

Cannot get sub-domain to work

April 25, 2011 8:49am

Subscribe [5]
  • #1 / Apr 25, 2011 8:49am

    julianps

    175 posts

    I have a site using version 2.1.3:20101220

    I have MSM enabled for this installation.

    Within one site I have set up a channel called “site2_weblog”, created a dns-valid sub-domain called “blog” and a template group called “blog”.

    In the sub-domain folder I have installed and modified index.php to include the site_name, site url and control panel url. Naturally when I point a browser at this sub-domain EE delivers options based upon the site (site2); that is to say renders out templates based upon the default group.

    Naturally if I create a path including the template group I wish to use I can reach the intended template but that’s somewhat inelegant;

    I prefer

    http://sub.domain.com

    to

    http://sub.domain.com/index.php/unnecessary_template_group_declaration/index/

    Sadly I cannot un-comment index.php fields for the non-MSM sub-domain solution as, whilst this does give me a path to the correct index file it only gives me a path to that file. I can no longer access comments, comment-preview, archives and other templates within that template group.

    does anyone possibly have a solution to this issue?

    Thanks in advance/Jules

  • #2 / Apr 25, 2011 5:01pm

    Brandon Jones

    5500 posts

    Hey Jules,

    Just to make sure I understand, is the issue that you can’t set a default template group independently on each site (main and subdomain?) You should be able to. Also, there’s no need to explicitly declare “index” at the end of your second URL example; it is assumed to be there if missing.

  • #3 / Apr 25, 2011 6:44pm

    narration

    773 posts

    I also hadn’t any success understanding what the issue may be here, but later one of those offside thoughts appeared which might help.

    It is that rules in .htaccess files, if you are using them, inherit to affect all directories below, unless you provide alternatives where appropriate in a local .htaccess.

    Subdomains work without issue on EE; many of us use them all the time. Subsites in subdirectories is the most common pattern.

    The standard advice in cases like this is to rename all .htaccess files to put them out of service, and get your sites working with the standard index.php in the url, also setting that properly as the name of your site’s index page in the Admin>General Configuration.

    Once you have all sites working correctly, then reinstate .htaccess files and work out your configurations, from top site directory downward and one at a time, so that you uncover any interactions.

    If this isn’t about .htaccess manipulations, please ignore.

    Regards,
    Clive

  • #4 / Apr 25, 2011 7:23pm

    Sue Crocker

    26054 posts

    Thanks for the assist, Clive.

    Jules, Clive is correct. You should temporarily disable your .htaccess file, and put back in index.php.

    Can you test that way?

  • #5 / Apr 26, 2011 4:04am

    julianps

    175 posts

    Thank you, all, for taking the time to reply.

    Brandon; yes, adding ../index/ to the url was a deliberate tautology ... 😉

    For the rest you are correct. Once I uncomment/populate the index.php variables $assign_to_config[‘site_name’], [‘cp_url’] and [‘site_url’] I appear to commit myself to the settings for ‘site_name’ (that is to say, to the settings of the primary (top-level) domain).

    Clive; I understand your point about .htaccess inheritance and I too have had success with addon- and sub.domains both with and without MSM, in the past. In fact the very issue I’m addressing in this topic is that a previously successful EE.1.6.9 MSM-based setup now no longer working correctly under EE.2.1.3.

    That said can I follow Sue in saying “thanks” for writing into the record a sound protocol for moving/relocating/testing EE installations in general.

    Subsequent steps I took;

    1) in the main site directory, renamed .htaccess to .htaccess.bak
    2) in the main site directory, renamed the file renamed_index to index.php
    3) tested main site functionality successfully (See note 1, below)
    4) in the folder assigned to the sub-domain, renamed the file renamed_index to index.php
    5) in the folder assigned to the sub-domain, commented-out the variables $assign_to_config[‘template_group’], [‘template’], [‘site_index’] and [‘site_404’]
    6) tested sub-domain functionality un-seccessfully (See note 2, below)

    Note 1 - This site has MSM installed and the primary site turned Off. Despite the site being Off I updated the urls, paths and index file settings to reflect those of site2, the only site we now use on this server.

    Note 2 - As expected, when I browse to the sub-domain EE defaults to using the index template of the default group

    Further steps;

    7) in the folder assigned to the sub-domain, un-commented the variables $assign_to_config[‘template_group’], [‘template’] and [‘site_index’] (See note 3, below)
    8) in the browser selected a link to the comments template => http://sub.domain.com/index.php/template_group/comments/url_title (See note 4, below)

    Note 3 - This did return template_group/template as predicated by the index.php situated in the folder assigned to the sub-domain
    Note 4 - After a pause EE returned the same template_group/template as per Step 7/Note 3

    And finally;

    9) in the folder assigned to the sub-domain, commented-out the variables $assign_to_config[‘template_group’], [‘template’] and [‘site_index’]
    10) in the browser, refreshed the link => http://sub.domain.com/index.php/template_group/comments/url_title (See note 5)

    Note 5 - At this point the ‘comments’ template renders correctly to the requested article and everything works as expected - the point being that it only works when the full url is rendered out, otherwise it returns the wrong group/template altogether.

    Conclusion.

    In my previous EE.1.6.9 installation I was having templates render by the simple expedient of editing path.php as follows;

    $site_name = “site_name”;
    $template_group = “template_group”;
    $template = “template”;
    $site_url = “http://sub.domain.com/”;
    $site_index = “index.php”;
    $site_404 = “404”;
    $global_vars = array(
    “my_weblog” => “site2_weblog”,
    “my_template_group” => “template_group”
    ); // This array must be associative

    However under EE.2.1.3 this process of mixing and matching the with-MSM and without-MSM addon-domain/sub.domain methodologies does not appear to work quite so elegantly (in my case, not at all).

    So the primary question remains; how, once MSM is installed, does one get sub.domains to work without buying a new MSM site licence for each sub-domain?

    Thanks,

    Jules

    ///// END /////

    Anecdotal Footnote (... feel free to ignore).

    This is my first migration from EE1.x to EE2.x and is the last I’ll do for free. As a previous protocol I’d always left the trigger word for the weblog module as ‘weblog’, included ‘_weblog’ in weblog short_names and included the term ‘weblog’ in both template_group and template names. The upgrade script changes some and not others and totally broke this site involving to date more than 25 un-billable hours of correction (most of the Easter week-end in fact).

    This installation involved a server change at the same time and although I got EE.1.6.9 working correctly(?) (sub.domains and all) yet the upgrade to EE.2.1.3 necessitated 30 search and replace actions to the configuration to get items such as the source of smiley images to operate correctly.

    Whilst the licensing terms permitted this process (and yes, all of the EE.1.6.9 files remain on this server, for roll-back purposes if necessary) common sense dictates that one copy the whole installation to a test-bed and get it working there first then copy the whole thing back. PLEASE DON’T though, as this will probably violate your EE license (or at the very least be very careful to ensure your test-bed version is set to Site=Off [Super-Admin Only] if doing this - and even then i’m not sure the license permits this process.).

  • #6 / Apr 26, 2011 11:20am

    narration

    773 posts

    All right, Jules; I think I may recognize what you’ve run into here, beyond the trigger word renaming issue. Let’s see if the following can help, as I believe it’s safe and to a point.

    I want to acknowledge first that it’s still difficult to follow through this level of logic verbally. On the other hand, I suspect it’s the level of logic necessary to describe the situation in narrative. My short cut will be that we’ve been through part of this before; jut not with an apparent mix of MSM and what we often call old-style or legacy MSM as you say you have.

    Here’s the basis—we established recently that although normal MSM is fine, legacy or old-style MSM hasn’t been working properly in most of 2.x, perhaps in all versions up to and definitely including 2.1.3. That’s been bug reported, acknowledged and repaired in 2.1.4beta, for at least the most practical variants of its use.

    I’m going to offer you a choice here, then, carefully.

    It may be that you need the whole nature of the 2.1.4 fix to get this complex site arrangement functioning again. On the other hand, there is a one-line source patch that might get you going at present without doing the 2.1.4 upgrade until it goes to release.

    The choice will probably hinge on whether it’s sensible for you to avoid setting the ‘template’ variable. In other words, if you can leave $assign_to_config[‘template’] commented out as in your tests, accepting that without this specification, the default ‘index’ template will be automatically provided for root url access of each site.

    Here’s the underlying distinction:

    - the source patch returns you to the ability to successfully set (in EE2 terms, through $assign_to_config[]) the ‘template_group’, which is typically the most important multi-site setting. However, you must not set ‘template’, as that will still lock your site to presenting only that template, since part of the original bug still remains.

    - the 2.1.4beta fix also returns the ability to freely set ‘template’ for a site, for the circumstances where that is actually needed.

    While 2.1.4beta has seemed very stable to many of us, and already repairs a number of edge points like the ones involved here, you’ve invested a lot at the present moment, and may want to wait until 2.1.4 is in release before upgrading. Thus I’ll point out the patch here that may sufficiently improve your situation, if you can fit with the restriction to leave ‘template’ always unassigned, and accept that it will be the usual default index template for each of your sites.

    You’ll find the patch, with it’s discussion, here.

    I notice in my commenting detail that url-addressing with the full path, e.g.  http://www.site.co.uk/template_group/index, will also still fail with this patch. I’m mention that just because it’s a case you might see in the way you are testing. I think it doesn’t normally come up in actually using a site which can also fit leaving the default template unset, so that it defaults to ‘index’.

    I think the patch is otherwise harmless, so that if comfortable you can try it. Be sure as always to have saved a convenient backup copy of the source file before proceeding.

    Here for reference is a note of what I tested as operating with the more capable 2.1.4beta fix. Note carefully that to use this 2.1.4beta fix, you are required to go back to setting the ‘template’ through $assign_to_config[], even if it is ‘index’, wherever you want to set ‘template_group’.

    Well, and note carefully, also, please, what I’ve discussed in that posting about Enable Strict URLs and one-segment URLs which name the template group only. The implication is that this does not work with the source patch on 2.1.3; only with 2.1.4beta. Then you’ll need to consider whether your site needs this, in making a choice to proceed.

    Jules, that’s what I can work out about this in the early morning here. Please keep us informed as you go forward, and let’s hope the door opens to getting your client’s site available without too much further work.

    Regards,
    Clive

  • #7 / Apr 26, 2011 11:42am

    julianps

    175 posts

    ...

    You’ll find the patch, with it’s discussion, here.

    I notice in my commenting detail that url-addressing with the full path, e.g.  http://www.site.co.uk/template_group/index, will also still fail with this patch. I’m mention that just because it’s a case you might see in the way you are testing. I think it doesn’t normally come up in actually using a site which can also fit leaving the default template unset, so that it defaults to ‘index’.

    Regards,
    Clive

    Thanks Clive, I made the suggested change at Templates.php#242, added ‘template_group’ to index.php (I added ‘template’ too, but commented it out with a note to uncomment it after the 214 upgrade). Everything appears to work again as all other templates/content is called explicitly.

    Best regards, Jules

  • #8 / Apr 26, 2011 11:59am

    narration

    773 posts

    Jules, wonderful, as I think you’ve got everything going, and you’ve also carefully prepared with the commented-out reminder for future upgrades.

    It might help Support if you could just confirm that everything about this episode is now complete for you—that will let them close this thread, thanks; and as they will say, you’re always welcome to post another, or to re-open this one.

    Best regards also,
    Clive

  • #9 / Apr 26, 2011 12:08pm

    julianps

    175 posts

    I’m good-to-go, please close the thread.

    Thanks again

  • #10 / Apr 26, 2011 12:26pm

    narration

    773 posts

    Good man, and I just remembered a footnote I’d like to make, with regard to another point you mentioned.

    Support can confirm this also (or not), but I believe a relaxed attitude is appropriate on use of EE installations for test and development sites—in other words, that Ellis would like you to feel free to do what you are comfortable with or need as far as staging servers, etc., and are not waiting to pounce on letter-of-law infractions.

    My interpretation is that so long as the site url is not publicly announced, you’re in good standing; as in that case, you and any client spokesperson or testers will be the only ones using it.

    Regards,
    Clive

  • #11 / Apr 27, 2011 2:35pm

    Sue Crocker

    26054 posts

    Thanks for the assist, narration.

    Jules - glad that things are working again.. Feel free to start a new thread if you have any more questions.

.(JavaScript must be enabled to view this email address)

ExpressionEngine News!

#eecms, #events, #releases