Thread

We are troubleshooting an e-commerce site built with a combination of EE (1.6.8 build 20091002 ) and Magento.

Unfortunately we did not participate in the construction of the site, and there is no documentation.  It appears that it was built using this method:

http://www.magentocommerce.com/knowledge-base/entry/tutorial-integrating-3rd-party-cms-content-within-magento

That is, EE actually resides in a subdirectory called “ee” and this hidden through .htaccess commands.

Now the problem is that EE Contact forms (using the email module) will not work because the action points to the site root where of course EE is not really located.  We have managed to get this to work by dynamically setting the form action on submit (adding back the hidden “/ee/” to the action value).  However this only works when we access the test form using the whole URL:

http://www.thedomain.com/ee/formtest

It breaks when we use:

http://www.thedomain.com/formtest

We get the native EE error page

[error]You are not authorized to perform this action[error]

I am assuming this is because we are attempting to post to a form FROM a page that appears to be outside EE.  Is there any attribute we could set dynamically (or any way) that would allow us to post in this way?

Thanks!
John

[Mod Edit: Moved to the CodeShare Corner forum]

John, I am not support, and also it is hard to get involved in this one due to the amount of moving parts, but since you’re not getting a response yet, I looked at that suggested Magento method.

It seems that the form is actually called with a prefixed ee subdirectory, according to inspection of the suggested code. Thus if it works by your manual test, it ought to work within Magento—did I misunderstand, and you actually tried it there?

I am not sure also just how much you’re using EE and in what other ways in the installation, and there can be an amount of trickiness I think in this because apparently Magento owns the url root index.php. Yet I don’t quite think you’re seeing any such effects in this particular case, since you are apparently successful running the /ee/formtest version of the path.

Let me stop with the light hand here, and hope a careful code inspection or testing variation will get you on the air.

Regards,
Clive

Hi John,

I don’t know of any way to do this based on that article. It’s possible that the intention is that contact forms should be built using Magento and not EE. This is a bit beyond a technical support thread though so I’ll move this to the CodeShare Corner for you.

Cheers

Greg

Thanks for your replies, Clive and Greg.

Clive: yeah the form failed when we treated it as if it were in Magento.  It works if we use an iframe to connect to the posting page.  The posting page and action URL need to be within the ee subdirectory.  I regret that my understanding is insufficient to support a coherent description of the issue.

😖

Thanks again, though.  And thanks, Greg for making the switch.  I’ll see about using Magento for the forms.

Hi John—ok, hold on a bit as I had a little different concept of this situation come to me yesterday, and think it can help.

Will write it for you in a few hours. Really, this situation ought to be pretty soluble, am pretty sure.

Regards,
Clive

Thanks a lot Clive!  I do have it working with an iframe; I think this will be acceptable, though it would be great to find a better way.  I really appreciate your help!

Hi John,

Glad the iframe is getting you through. I thought it worthwhile to see what was what with the original idea from Magento. Actually, I think it’s sound, and may be able to suggest what’s going wrong.

The whole key is that any ‘path’ information following the ExpressionEngine root directory index.php is actually going to be treated as EE routing information, rather than filesystem paths. So anything that gets you consistently to that root directory, and critically its index.php file, should work.

I now understand what Magento is doing, in using its 404 handler to send any pages it doesn’t recognize to EE, and it is doing so by repathing those to the /ee/ directory.

The key to making it operate is in that .htaccess file they post at the top of the article. That .htaccess has to be in the /ee/ directory, by their layout, so that it can properly instruct the webserver. Then a request which tries to use the /ee/ directory is going to have index.php prepended to it.

This will cause the filesystem ‘pathing’ to stop, and EE will now use what’s left of the path, on executing the index.php, as normal routing within EE. That means your appropriate template group and template will be found—or the default index template in the default template group, if there is no routing after the /ee/ in the calling path.

EE then works as it’s used to working when it receives its index.php call, and has no idea Magento is there, save for the fact that they had you design the EE pages to include the Magento header menus so that you can transparently click and go to a place in Magento.

I know this overall Magento-proposed method works because it parallel to what I and others use in the so-called ‘old method’ of multiple site management, so that we can for example run a number of in-development EE sites off one EE executable.  I’ll pass you a URL in a private message which you can apply as follows, and see it work:

—use the URL alone, and you get my current if on-hold and not publicized main site
—use URL/ae, and you’ll get an EE showing just the Agile Records demo—which is targetted by the index.php in the /ae directory, just like your Magento workup uses an /ee directory. This no-extra-paths case is the result of just adding the index.php without routing, as my .htaccess does similarly to Magento’s.
—use URL/ae/about, and you will see the Agile demo About page, properly, as if you’d pathed siteroot/about.
—use URL/ae/about/contact, and you’ll see the Agile contact page, properly, in the same way. The Agile demo has its contact page pathed/routed under the about template group, just so there’s clear understanding of what’s going on there.

Thus what I am suspecting is going wrong for you is that your /ee/.htaccess isn’t set up properly according to the Magento article—or maybe it isn’t there at all, or is placed in another directory through misunderstanding. The one other possibility that comes to mind is that mod_rewrite isn’t installed on your Apache server, or equivalent, but usually such a thing is present, and that .htaccess is not a stressful one.

As with my site, you should be able to test and debug all this by direct URL from browser, without Magento involved. Afterwards, the Magento handler in the article should work as expected.

They talk about handling real 404s - mis-addressed pages, at the end of the article. In their method, EE will actually be handling those, and that’s likely a much easier thing to set up however you would like it to look and act by EE normal methods, than anything external as they suggested might extend their method.

Hoping this will get you there - it’s simpler even than I thought, and saved me from having to invent substituting regular expressions for this, as had started to.

We’ll be interested to learn what you find—and very likely useful for others, John.

Regards,
Clive

I just tried resolving same issue doing an EE/Magento integration with a search form in EE. All I did was give the form a unique id:

form_id="form-id"

and wrote some jQuery to change the action of the form. I put the script right above my EE form code as it wasn’t working in Magento head. Hope that helps someone in the future!:

var url = "{site_url}";
       $(document).ready(function () {
        $("#form-id").submit(function () {
         $(this).attr("action", url + "ee/index.php")
        });
       });