Before I get to the question, let me say that I saw a similar question here with a fairly detailed response:
https://wordpress.stackexchange.com/questions/115211/loading-wordpress-stuff-on-laravel-site
And it was the closest thing I have found on the web to what I'm looking for, but the potential solution looked like it might end up being so laborious as to not be worth the time. Here is my situation:
I develop and maintain a small custom SaaS program that typically functions on a subdomain of a client site (say, software.client.com). The latest version of the code was rewritten using Laravel and there were a lot of gains associated with that. In the past, when the program was basically procedural spaghetti, if we had a client with a Wordpress site on their primary domain, we ran some atrocious (by best-practices standards) hack-around code to pull the Wordpress header and footer onto the pages of my program - sitting, of course, outside the CMS - while modifying meta tags and doing a number of other things. It wasn't pretty but it worked.
Now I'm in a situation where I'd like to solve the same problem - that is, to at least pull the Wordpress headers and footers onto some of the Laravel subdomain views - but nothing I have found on the web so far has enabled me to make much progress in that direction. I have found a lot of tutorials explaining how to integrate Laravel and Wordpress, or use one for frontend and the other for backend, etc., but nothing yet about the specific type of integration I'm talking about.
What I have tried so far is implementing some of the code I've used elsewhere into various parts of the Laravel codebase. Most of the recent experiments have been in public/index.php and in Controller methods. Laravel will allow me to get as far as including the Wordpress config, but if I attempt to go any further I cause a 500 error. Here's an example snippet that actually attempts to do more than I need, but I can't even get past wp_init(). Imagine the following code in a Laravel Controller method. The first two lines are OK, but:
public function index() {
define('WP_USE_THEMES', false);
require '/path_to/wp-config.php';
$wp->init(); // from here on, 500 errors occur
$wp->parse_request();
$wp->query_posts();
$wp->register_globals();
// And then, at some point, I would call and modify get_header()
(I didn't really expect this to work from the Controller, but it doesn't work from anywhere else in the codebase I've tried either.) This is not a situation where I want to hand off control from Laravel to Wordpress for these URLs (I need Laravel functions / DB queries and more flexibility, and I know I could just do that hand-off through public/index.php and routes.php if it would solve the problem). And for these intallations, I don't need to grab posts or other items from Wordpress. I would just like to find a way to pull the header and footer into these views directly from Wordpress while maintaining control of the views in Laravel. If I can't, among other things, the design team will end up rebuilding headers and footers for every program install on a Wordpress client (for the time being) and they will have to make changes in at least two places when things are modified or updated.
If we have to, we will find a way to live with that until the next program version rollout, but if I can build a solution in what my superiors will deem a reasonable amount of time, we would all be happier. I hope that I have just missed something simple somewhere and I will be embarrassed to find out that I could have solved this in less time than it took to explain the problem. Thank you for any and all helpful responses and potential solutions.
You're not going to be able to cleanly merge the two codebases together. That would cause a disaster.
The complexity of the solution depends on the complexity the information you need to share. The simplest solution possible would be to write something custom to WordPress that builds a document with no body data and just supplies a token, like {!! $body !!}. Then, in Laravel, you can do an HTTP request to localhost to fetch this tokenized content. Store the result in a memory cache and use Blade to render the final view.
Essentially, my suggestion boils down to: Create a Blade layout with WordPress.
There's a thousand different ways to do this, and all of them are wrong.
Related
Our main web page is Drupal and we would like to use Osticket as our issue tracking system, but there is a problem with Osticket: anybody can create new tickets.
We can protect this by .htaccess, but we don't want do that; we would like to make this protect by Drupal: only authenticated users should access the Osticket page.
Is there a way to achieve this?
Found a solution here:
http://osticket.com/forum/discussion/9910/integrate-with-drupal-7
Here is the relevant part:
Preamble
It just so happens I was doing some off-again on-again work with integrating this into Drupal.
If you're just interested in ensuring a user is logged you're right, you need bootstrap.inc and you're right you end up with useless blank pages.
Solution
I've yet to get to properly documenting, so try this and let me know if I missed something and I'll have another look, however the following should sort the issue:
Duplicate Function Names
osTicket uses db_query() and (I think) db_close() rename the functions to something like db_ost_query() and you'll be fine. (Note I put the 'ost' in the middle to help future find/replace) I can't remember whether all occurrences of the function needed renaming for it to work, but its probably a good idea to do it.
Location of the bootstrap
The bootstrap has all manner of issues if called from outside the root Drupal directory, I gave up finding an answer to this and just kept an file in the root that osticket would include.
Headers, Headers everywhere
Bootstrap seems to like sending additional headers out so you'd want to include your file in an appropriate location (i.e. one of the .inc files). I think this solved everything.
Disclaimer
Of course, remember this will break on any updates and any mods you add you'd have to take this into account. If I've remembered rightly this will get bootstrap up and running and you can run is_user_logged_in() and show or redirect the page.
Further Concerns
I actually had a greater goal in mind in my meddling and so I don't remember whether everything was perfectly cosy after this addition.
I do remember having further issues with headers being sent and when fully bootstrapping the system session usage interfering with ostickets sessions - I think this occurred later though and shouldn't be an issue for you.
An Alternative Solution
When googling, many people suggested simply creating a module and having it iframe the contents inside it, this might be a good enough solution for what you want and would require a whole lot less messing around with ostickets code.
Several popular CMS's such as Drupal, Wordpress, etc. have an index.php file that is pretty much empty except for a include/require statement that includes some other PHP file (as in one file) containing all of the bootstrap code for the CMS. What is the rationale for this? Why not just move all of the bootstrapping code into index.php if it is doing nothing other than including the bootstrapping code anyway?
I'm trying to build a CMS as an example project to improve my PHP skills, and I'd like to understand what design considerations led them to do it this way. I understand the benefit of breaking up applications into multiple files, but I've never heard of making a file that does nothing but include another one. Obviously there is some benefit, since several major CMS projects designed it this way, but I just can't figure out what it is.
Can someone explain to me the reasoning for this?
In Drupal's case, there are other files that do a similar bootstrap. These typically aren't normal pages, but do serve important purposes. Off the top of my head cron.php, update.php, and install.php do this. I use the bootstrap process at the beginning of custom import scripts, as well as scripts that get called by cron that I don't want to use a hook_cron for.
I can think of two reasons:
When using a product like Wordpress, you sometimes end up adding user hacks to the front controller - say, setting custom constants, specific redirects, or an additional layer of access control, or whatever. An empty index file allows you to add that kind of stuff without disturbing the product's original code.
Having everything in a separate bootstrap creates the possibility of moving all code (including the bootstrap) to a location outside the web root, and include it from there.
Aesthetics mostly. You can have a clean and neat directory structure (outside of webroot), in which bootstrapping files are separated from index.php file. There are probably several of them (vs. one index.php file) and they are doing different things (db init, authorisation).
I also found one or two CMS which start in debug declaration (in order to switch display errors and warnings before including any files, so you can have your errors printed before php includes a file with syntax error, but that's not really a good practice).
I would say this is good design because you can easily change the path to the bootstrap, which makes it very easy to change location of the CMS, if ever necessary.
Another good reason is you could also be running a dev CMS while developing, and roll out new versions with one path change in the index.php.
(I've posted this on the drupal forum too btw)
I'm converting the company websites to use Drupal, or at least trying to check that its going to be the best way forward. I have a background in PHP development, and I'm currently using the CakePHP framwork. I've built this site (not my design) and I can see how to replicate most of the functionality using Drupal, most likely using the CCK module.
http://preview.tinyurl.com/yk6u8mt
As you can see from the homepage:
A user chooses a country.
The country is passed using an ajax call to a script that decides which phone is best based on 'in country' network coverage.
A div is shown recommending the visitor the best phone for that country.
I'm wondering how to go about this in Drupal, I'm definitely not after a step by step guide, I just want to know if this kind of thing is possible with Drupal, and what approach to use.
If someone can help that would be superb. Thanks.
Okay, so you've got a path you're defining in hook_menu, which is where your form is being presented - or else you've got it set up as a webform in a node, that could work too.
Either way, in your form you're going to be using AHAH - check out http://api.drupal.org/api/drupal/developer--topics--forms_api_reference.html/6#ahah and http://drupal.org/node/348475 .
Basically, you're going to define another path in hook_menu that's of type MENU_CALLBACK, and which will receive the country as input, and then will return the div that you'll display on the screen.
One core example of AHAH that may be useful to you is where you're entering a password and it lets you know if the password is secure enough - check that out.
Edit: There's also some good examples at http://drupal.org/project/examples.
I would look into using CCK and views. you can set up filters for the views. If filters don't work, you have the ability to include php code. I have also successfully added jquery code in the header of a view through which I was then able to have my view filtered by what is typed in a text box.
Coming from CakePHP using Drupal is a pain in the a** - even more for developers.
It's application structure might be designed to ease extensibility but this only means you have a system to enable your own plugins and themes.
While modules are basically the M+C-part the themes are the V-part of an MVC-application. The problem is that this seperation is not very strict in Drupal - in fact you have to break it sometimes in order to make things work (e.g. you have to include a theme_mymodule_myfunction() into your module as default output which you then can override with your theme using mytheme_mymodule_myfunction() ) And don't even bother looking for classes ( see http://drupal.org/node/547518 ).
Also there is no real link from a module to a theme. On many occations this is a good thing as you can switch modules and themes seperatly without creating a problem. For application builders coming from CakePHP (or any other framework) you often feel a lack of "wholesomeness" - you create parts for a base software and have to live with it's drawbacks.
IMHO I wouldn't recommend this step. Drupal is fine if you have to manage a website and might add a few modules to add neccessary value (image gallery etc.) but I definetly don't recommend it as a base for a customized web-app.
I starting working with WordPress as a CMS, now that the V3 makes it way easier to manage taxonomies and custom post types. My work is mostly focused on developing plugins and themes.
My biggest plugin does some admin stuff (add admin menu items and the related pages and features), but also does some importing and exporting, and hooks some of the base post processing treatments ("when a new post is created").
My biggest theme is pretty small, and all it does is display custom posts in a custom way.
After a few weeks of work, I have several thousands of LoC, and it's getting harder and harder to dig into it. Which leads me to the following question: How do you organize your WP plugins code? And what about your WP themes code?
several thousands of LoC
That's pretty epic! I've always found the beauty of WP is that I can, as jQuery put it;
Write less, do more!
You might be much better off using Pods CMS alongside WP to cut down your code.
This is how we structure client deployments that include themes, third-party plugins, and custom code.
wp-content/plugins only contains third-party plugins, no code in here is modified, and the site should not be deadlined by any of these plugins being disabled / removed.
wp-content/themes should contain the code related to presentation of the front-end. The trick is not not overload the theme (functions.php and other theme-related files) with code not directly related to presentation.
mu-plugins/ contains all of your implementation-specific business logic. Things in here should never be disabled, and are required for operations.
That is avery brief summary, but in a nutshell that is the logical compartmentalization of code that we've found to be most failure proof.
Why not to split plugin into several files by function? The same goes to themes. Any problem you have with that?
There are basically three ways you can do this: prefixed functions, with require_once's including files by functionality, which is quite common.
The other "right" way that's touted a lot is having one giant class with all your plugin code in it. While keeping things nice, as you said, once that file gets into the thousands of lines of code, you're screwed for manageability.
The way I like to do it is a way coming from my C# background - have one main plugin class, and other "worker" classes (you can put them in a namespace to keep classnames short). For example, have a class dedicated to the admin section (it can have its own little "subclasses" too, say one for each page). It'll take a while to refactor all this code into the different classes and files, but it'll be worth it - it'll be much easier to keep track of everything, as well as for example getting people to work on the codebase together. It also forces you to think more of how your application all fits in together, which lends to better thought out code.
I'm actually writing an article series about this, outlining the three different methods. You can take a look at the first instalment here. There are two more coming in the following weeks.
Hope I helped!
Has anyone ever tried to integrate AspDotNetStorefront and Sitecore? I've been trying for the past couple of days to come up with a way to get the two systems to play nicely together, but it doesn't seem feasible from what I can tell. A couple issues I've run across so far:
Authentication between the two (AspDotNetStorefront has its own implementation, Sitecore just uses/extends .NET Membership)
The main DLL for AspDotNetStorefront is what pops up in the stack trace when I get yellow-screened, but that DLL is obfuscated so I can't figure out what the problem is.
The biggest issue is that we need to keep our existing AspDotNetStorefront application as an e-commerce backend and use Sitecore to do everything else. AspDotNetStorefront has a CMS as part of it, but it's really not an acceptable solution for anything but really basic content pages.
Any thoughts on how I might go about this?
EDIT:
I've decided to break this whole thing down into the different problems that I am facing at the moment and solve each one as efficiently as I know how. I'll detail the ones I have here and then update when I run into new ones.
Problem 1: Authentication between the two systems.
This one isn't too bad actually if you're knowledgeable about forms authentication tickets, which I wasn't at the time but am learning quickly enough. As long as the two systems share the same encryption info, it's easy enough to pass information back and forth between them using cookies as stated below in the accepted answer. The other kicker is that I needed to set the CustomerGUID in the AspDotNetStorefront Customer table to be the user ID from the Sitecore user tables (standard ASP.NET membership). So far this approach seems to work pretty well (I'm still in the proof of concept stage at the moment.
Another thing to keep in mind if you ever need to attempt this is that AspDotNetStorefront comes with a web service that you can use to basically do anything you need. Since they use the same encryption keys, I am able to log in on the storefront side using this service more securely than just passing over clear text passwords (I had to write the method myself, I don't believe it comes standard, if I am mistaken please let me know). Although I doubt it's a huge deal since it all happens server side anyways.
Problem 2: Getting at the product data
This one was a little more troublesome. The aforementioned web service has a few issues I've had difficulty working around. However, since the databases are going to be on the same server, I simply decided that since all I really need is the price and ID I would go ahead and set the ProductGUID column of each product in the Storefront database to match the Sitecore item ID of the corresponding item in the Sitecore database. This way I just need a quick query to grab the ProductID and price information which is only used in a few places. Everything else is going to be housed in Sitecore.
If anyone has anything to add feel free, as far as I can tell from Google, no one has actually done this before, so I'm having a lot of trouble finding resources on this particular topic.
UPDATE:
The integration is in fact possible and our site has been up for a week and a half now with very few integration related problems. This isn't something I recommend doing really on a personal level, but it is in fact possible to pull off.
I know ASPDotNetStorefront and other CMS systems (but not Sitecore). If I was approaching this, I would probably start simple and create a custom URL structure for sitecore 'content' pages that ASPDNSF would direct to Sitecore to handle. [possibly replacing the existing topics system in ASPDNSF]. So, for example: a URL such as www.domain.com/p-1234-aproductpage.aspx would be handled by ASPDNSF whereas www.domain.com/content/123/a-content-page would get sent to Sitecore to render. This is a straightforward web.config edit.
Security sharing across the systems should be possible across the same domain as the cookie information will be available (you should be able to create some code in Sitecore using the ASPDNSFCommon.dll and a cast of HttpContext.Current.User into a AspDotNetStorefrontPrincipal class to detect if a customer is logged in)
Another way to approach the problem would be to write a function that retrieved Sitecore content from the database based on a URL id and then write an ASPDNSF XML template to use the function to retrieve this content based on the URL. For example, you could create a custom URL structure in ASPDNSF such as www.domain.com/sc-1234-sitecore-content-item.aspx which is sent to your custom code; 1234 is used as the sitecore content id and the XML template retrieves the content and renders it on screen.
This second approach has the advantage of using Sitecore for all non-product content management while keeping the live application in ASPDNSF. Also one set of design templates and all your security issues go.