I have a deployed production Saas business built using node.js framework running on Heroku Cedar (http://EasyNDA.com). Now I would like to have a well integrated blog (the hack that's on http://Easynda.com/blog as of today is an iFrame from wordpress.com - many shortcomings).
I have a separate Wordpress.org PHP application on Heroku; however, these are separate applications on separate servers -
Is there a way to integrate Wordpress.org with my Heroku node.js application so they can be tightly integrated from a UI and URL perspective? Can a Heroku node.js Cedar instance be made to also serve Wordpress' PHP? or is there another way to do this smoothly?
You cannot run a single Heroku app with multiple languages, so you'll need to keep these as two seperate applications.
You definitely don't want to continue with the iframe since each individual post/page wouldn't be accessible via the url, and lot of other problems (which it sounds like your aware of).
Easiest solution would be to have your blog on blog.easynda.com (using a subdomain instead of a subfolder).
Then I'd suggest using a shared css file, and duplicating the html elements as much as possible. You want to keep as much of your html layout identical between the two (in terms of your header, footer, nav, etc.).
When you're mixing languages first ask yourself, can I do this all in one language? There are Node.js blog options available that may meet your requirements so I'd suggest looking at that first: Ghost
iFrames should generally be avoided unless there's absolutely no other options available. They generally create a horrible user experience, scroll bars in scroll bars, bookmark issues, all kinds of nasty stuff;
If you must mix multiple languages, like Node and WordPress, look to use a simple REST API in JSON.
WordPress would only control the content then your other app could still maintain everything else for a seamless experience. This would only be my second option since you'll still likely need two different hosting environments, need to deal with different security updates on the two apps, etc.
If we're only talking about a simple blog you might be better off just building one entirely. Then you don't need to spend time worrying about integrating and learning the system.
Related
In the creation of a simulation for our company, we coded the entire thing in R. It runs on AWS, and the consumers have been given links that route to the AWS page. Our website, however, is currently running off of Wordpress. In order for our customers to be able to access the product, we need to find a way to connect the product to the website. We would hence like to replace the current site with a new one that allows users to access our simulation from the website.
The only option we’ve come up with is to create a separate domain that has the interface built into the R program, and have a link to that domain from the current website. However, we would prefer to have a more direct solution.
Do any of you have any suggestions as to how we might achieve this?
Thanks for your time!
This answer very much depends on your code, but I think you have several options.
Run on external website
Pros:
Full control over code, easy to update without risking changes to main site
Easily accessible either by directly linking to it, or using <iframe> (HTML) on your main website, no Wordpress support required!
Cons:
Separate domain, some extra costs (?)
Shinyapps.io
Pros:
Easily publishable, often free
Cons:
Available for mostly everyone, which might not be ideal in a business situation
Less control over the platform
EDIT: I wanted to add that you can host your own shiny applications, and build the front-end using HTML. This gives you some more control.
AWS
Pros:
You should be able to set up an instance where the simulation is run on a subdomain that is not directly tied to Wordpress, e.g. outside of the main Wordpress folder.
As I said, the ideal solution depends on your code. Does it take user input, does it need to save files often? What kind of access control do you need?
I was looking at some larger scale Meteor applications and was wondering why some of the initial sites do not seem to use meteor.
As an example when you go to classcraft and look at the main website you notice it is not using meteor.
Then when you go to their actual application (click signup for example) you can see it uses Meteor.
So they make a clear separation in terms of technology. Can someone explain the reasons? Is it not as efficient / clean to just use Meteor for the whole thing.
Thanks,
Jean
Each company makes their own decisions on how/when/where to use technologies. In the case of meteor, the really strong part of meteor is that it's real-time updating. That means things like messaging systems, getting updates out quickly, etc. good uses for meteor.
It appears as though classcraft has decided they don't need that capability on the home page. There's also some concerns with SEO and meteor that perhaps classcraft didn't want to deal with.
Finally the home page not being built in meteor shields the DB from public view, which is not a huge security advantage, but may be one they considered.
This is all me finding reasons for them as I don't know why they'd make that decision. I don't make that decision for my sites/apps but that doesn't mean others might not see things differently.
I'm the founder of Classcraft. To answer your question, it's because we didn't need everything Meteor had to offer for the front-facing website : reactivity, flexible templates, a database, etc. Meteor is amazing for building apps, but it's overkill for a static website. Also, if the front-facing website was built within the game app, it'd mean that any copy changes or tweaks to the front-facing would cause us to have to redeploy the app, which means some downtime (not much, but still) for our users. Keeping them separate also allows marketing people (who aren't developers) to tinker with it without going into the code base for the game.
We decided to build the front-facing website using middleman. Middleman allows you to generate a precompiled static website, which allows for amazing speed and simple server configuration (it's served from S3, which means it's super fast).
I'm sure the reasons are different for everybody, but that's what it was for us.
Shawn
I'm starting work on a personal site that's primarily a blog, with a section for various tech projects as small as a custom photo gallery to as large as a restaurant-review web-app. Not having worked with WordPress or Kohana before, I'm curious what the advantages are of integrating WP into Kohana (or any other framework, for that matter), and vice versa, given this situation.
I've seen bits of this mentioned here and there online, but no definite post comparing the two approaches, so I'm hoping others can pitch in here :)
I've not used this before, but kerkness has written a plugin for it: https://github.com/kerkness/kohana-for-wordpress However, it is quite old so you might want to look for something newer.
Integrating Wordpress with a framework (be it Kohana, CodeIgniter, Zend, etc.) is often sought without addressing the first and most important question: How far do you want to integrate the two at a feature level?
Broadly speaking, there are two high-level approaches to integrating any two PHP products:
1) In the PHP code, include the libraries, bootstrap scripts, etc. from both products into a script or scripts (creating a "hybrid").
As a developer you should be able to use most of the features from both products in the resulting hybrid. For example, in the case of Wordpress and Kohana, the complete result would allow you to use Kohana features (e.g., routing, auth, etc.) and Wordpress features (e.g., fetching post contents, authors, etc.).
The difficulty with this approach is competing APIs and code expectations that might make the hybrid behave unexpectedly, e.g.,
Will there be competition between the class autoloaders?
Are there duplicate function or class definitions?
How extensively can plugins in Wordpress be supported if they depend on PHP settings that the framework is going to change on bootstrap?
The first issue I would want to resolve when attempting this process is the routing, am I going to delegate fetching of posts, attachments, etc. to Wordpress from within Kohana, or am I going to have to build an interface between Kohana's router, controllers and Wordpress?
While this option is appealing because you can access both product APIs, you must be prepared to make significant changes to the application behaviour in order to allow both products to co-exist peacefully. If this sounds like a lot of work, it is because it is a lot of work!
2) Use the webserver to intelligently route requests to different products.
From your question, it sounds like you want parts of the website to load web applications that don't necessarily need the level of integration indicated above (e.g., would you really need to get Wordpress API in the review application, or the photo gallery?). If you are just looking for a way to load two applications using the same application domain, this option would be better suited because you don't need to perform much (if any) integration between the two.
Assuming you are using a webserver like nginx or Apache Httpd, you should be able to create aliases for different parts of the site to different applications.
e.g.,
http://myblog.nonex/ - points to the Wordpress installation, which in turn manages the default site (shows pages, blog posts, etc. all from Wordpress).
http://myblog.nonex/apps/review - points to the review application, which is the Kohana installation.
http://myblog.nonex/apps/gallery - points to the gallery application, which (with proper modularisation) could exist alongside the review application in the same Kohana installation.
Since you are still in the planning and development stage, I would recommend going for option 2) first - build a prototype, identify any areas where you absolutely need features from Wordpress in Kohana (e.g., would either the review or gallery application need to use the Wordpress user credentials?) and look at performing a minimal integration before creating a full hybrid.
We have a series of ASP.Net applications that have been written over the course of 8 years. Mostly in the first 3-4 years. They have been running quite well with little maintenance, but new functionality is being requested and we are running into IDE and platform issues. The apps were written in .Net 1.x and 2.x and run in separate spaces but are presented as a single suite of applications which use a common navigation toolbar (implemented as a user control). Every time we want to add something to a menu in the nav we have to modify it in all the apps which is a pain. Also, the various versions of Crystal reports and that we used tables to organize the visual elements and we end up with a mess, especially with all the multi-platform .Net versions running. We need to streamline the suite of apps and make it easier to add on new apps without a hassle. We also need to bring all these apps under one .Net platform and IDE.
In addition, there is a WordPress blog styled to match the style of the application suite "integrated" into the UI and a link to a MediaWiki Wiki application as well.
My current thinking is to use an open source content management system (CMS) like Joomla (PHP based unfortunately, but it works well) as the user interface framework for style templating and menu management. Joomla's article management would allow us to migrate the Wiki content into articles which could be published without interfering with the .Net apps. Then essentially use an IFrame within an "article" to "host" the .Net application, then...
Upgrade the .Net apps to VS2010, strip out all the common header/footer controls and migrate the styles to use the style sheets used in the CMS.
As I write this, I certainly realize this is a lot of work and there are optimization issues which this may cause as well as using IFrames seems a bit like cheating and I've read about issues with IFrames.
I know that we could use .Net application styling, but it seems like a lot more work (not sure really). Also, the use of a CMS to handle the blog and wiki also seems appealing, unless there is a .Net CMS out there that can handle all of these requirements.
Given this information, I am looking to know if I am totally going in the wrong direction? We tried to use open source and integrate it over time, but not this has become hard to maintain. Am I not aware of some technology out there that will meet our requirements? Did we do this right and should we just focus on getting the .Net streamlined? I understand that no matter what we do, it's going to be a lot of work. The communities considerable experience would be helpful. Thanks!!
PS - A complete rewrite is not an option.
Hmm, we're in the midst of a project to do something that sounds familiar. We're using www.sitecore.net CMS but you could use the Open Source alternative Umbraco again both of these will have a learning curve, but they're .Net apps and aren't targetted specifically at blogs. SiteCore ultimately can use normal .Net user controls if you want, though it's slightly against their model, but it works.
One thing I'll warn you of is SiteCore Must be the root of your website, it has to control the root of the domain (it has a urlrewriting module that needs to be at the root) and you can tell it to exclude certain folders where your applications might live. You can obviously put your navigation in a folder under the root of the site. Also note SiteCore's a .Net 3.5 application running under the 2.0 runtime.
Are your sub-applications.. Actual seperate applications in virtual dirs or something I'm guessing?
Depending on the nature of the .Net apps, you may find DotNetNuke to be a useful choice.
It's a CMS where you write widgets ('modules') in .Net, then add them to the pages of the CMS. In your case, you'd wrap your existing functionality in such widgets. I've done exactly this several times, and now that I'm used to it it's no big deal.
The downside is you have to learn to swim in the DNN environment, which (like any CMS) has a bit of a learning curve.
I'd have to know a lot more about your existing apps to be sure this is a plausible option. If it looks appealing, you should probably contact someone who's dealt with a situation like yours (such as myself) and go into detail. It's very easy to find yourself in a dead end with these CMS frameworks.
Edit: Like a product mentioned in a different answer, DNN has to control the top level of its subdomain -- all requests begin by going through Default.aspx and are then dispatched in various ways.
A friend of mine really likes using Joomla as a base for his websites. He also likes the power that Asp.Net has and can code in VB.Net.
He wants to use Joomla as the "Master Page" and Asp.Net/VB.Net/SQL Server to handle the main business logic of the application. He is planning on using the Joomla Wrapper Module (an IFrame, joomla modules) to integrate the ASP.Net into the Joomla website.
Joomla will be able to handle the security (users,roles,registration), menu (based on roles), static content (e.g. About Us page) and it will pass an Encrypted Username & Password to the Asp.Net web page (example here).
The goal of the website is to allow users to register & subscribe to a (free or paid) service where they will be able to customize content and download it as a file.
What disadvantages are there when doing this? Are there work arounds?
Some issues that I can think of are:
Links clicked in an IFrame won't change the browser's url which means that you can't bookmark pages and they aren't in the browsers history.
If Asp.Net has to know the users/roles (which is very likely) then it would have to access the Joomla database or keep its own user table which will have to be in sync with Joomla's users.
EDIT:
I would never build a new website this way, but I was looking for concrete points to convince my friend that using Joomla and Asp.Net together isn't a good idea.
I believe your friend's idea is fine. Both platforms have strong points. Joomla is a mature open source CMS platform that has an enormous amount of community contributed components and it is easy to use which makes it appealing. But I can also see instances where you may want to include ASP.Net functionality in certain scenarios. I have had clients who use Joomla but wanted an app I have written in .Net and it did not make sense to spend the time or money to rewrite it in PHP and MySql. The two can be integrated securely. I wish your friend luck in his endeavors.
I don't see what advantage you get from using Joomla when the app is ASP.net (nor the advantage of coding an ASP.net app when the framework uses PHP/MySQL).
I'm not convinced the security is tight because you can open iframes and bypass the Joomla security. Then you talk about passing username/password to the iframe - but now you need to validate this again through the ASP.net app.
I once coded an app in raw PHP and included it in a Joomla site using iframes. I realized fairly quickly that there was basically no security because the raw PHP had no knowledge of Joomla (although the app was not visible to site visitors and only known about by admin). I quickly recoded it into a built-in component.
To me, this sounds like you're reinventing the wheel on both sides of the app. If you want to use Joomla, either learn how to make components (it's pretty simple) and do it in PHP, or hire someone to do it for you ;).
If PHP is not your strong point, then use a full ASP.net site, perhaps with a CMS as GmonC suggested. Even creating your own basic CMS with some pre-built components (e.g. Telerik) would probably be quicker than integrating PHP and ASP.
Seriously, IMHO, if you're not going to integrate some legacy system or isn't doing this kind of "integration" development as an "experiment" to learn something - in a summarized way, if you just want to have your work done, I think the description you provided inserts a lot of complexity and overhead that aren't needed in the first place.
This added complexity of two completely different ecosystems is a disadvantage to what should be just simpler. I really believe you should try to use Joomla or other CMS written in .net like dotnetnuke (or build your own) instead of this configuration.
If you add more information about what are the goals and objectives of this project, my opinion may change. Until them, I keep my opinion of simplicity.
The time and effort you are going to go through to use Joomla is going to far outweight what it would take to just get some other CMS that was designed for .NET.
Stop over-engineering yourself into a midlife crisis.
Also, Joomla? Seriously? Joomla?
me too don't get any advantages for joomla, it's big system and it just as good as wordpress for regular projects, just wordpress is much simplier. joomla has no good documentation to learn and hard to extend.