There are a few tutorials on the web regarding the multi apps structure with Symfony 2, however I haven't seen any post on cross linking the apps (in term of http urls, how do you generate a link to the frontend blog post from your backend application?)
It's possible to put all the shared routes in a shared bundle, but then how do we generate the apps with the correct application path applied to it? For example, in my case I need to generate mysite.com/reset_password but since I do it from the backend I always get mysite.com/backend/reset_password. Of course I can trim the /backend/ out manually but that does not seem like the way to do it.
PS: I understand the downside of the multiple apps structure, however there are reason we want to use it.
As far as I know there is no built in way to do that, but it doesn't sound especially difficult to do.
Create a web service on the site you want to link to which provides URLs to specific locations. You can then normalize these URLs to generic keys. Then create an internal service to build a URL from this data.
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've read a lot on this topic, but cannot find out a clear answer on how to structure a complex project around symfony2...
My new project will be structured with :
1) one back office website hosted on a subdomain of our partner's website
2) one partner's website
3) one (or more) customer's website
Of course, each of these websites will share logics from "core" bundles (i.e : core entities, core user logic, etc...), but they also need to have custom routing, custom templates, and so on...
I think that I have 2 options :
1) define 1 bundle per website and define routing based on the hostname, but it seems that it is not recommended
2) implement one SF2 instance by website, and copy/deploy core bundles into each instances
What is the best solution ? And is there another solution on how to implement some kind of complex project?
It's difficult to say which is best for your particular situation: I've used both approaches for projects. I actually have one project which uses both approaches simultaneously, consisting of two Symfony applications: One generating the main website, the other generating a separate application containing some other functionality, with separate bundles for the "user" functionality and the "admin" functionality. We used Varnish to dispatch requests to the correct application, based on the URL path.
In my experience I've found that having multiple applications adds a degree of complexity to the overall solution. This makes it more complicated to work with and to hold the "big picture" of the whole system in your head. There's also potentially a cost implication, if you want to run your applications on separate servers. You also need to consider that there's overhead on getting the whole solution set up for local development, which is definitely a concern if you're in a team of more than one.
The flip-side of this is that working on one part of the whole solution (i.e. one app) is often more straightforward: Configuration values/dependencies for the other applications won't need to be set up, you only need to get working the bare minimum for that one standalone app. This approach also affords you a lot of flexibility and the ability to concentrate changes on one particular area of the solution. For example: If you wanted to make some changes to the partner's website, if that was generated by a completely separate application, it becomes straightforward to do this. You know that there won't be knock-on effects to your other applications. This goes for shared code too, providing you version it correctly: With composer, your separate applications can depend on different versions of your shared bundles/libraries if necessary. Another benefit of having separate applications is the ability to scale them independently of each other. If your customer website gets much more traffic than your partner's site, you can set it up on better hardware/virtualised instances, giving you finer grained control over performance/costs.
Sharing code is relatively straightforward with Composer and is not one of the main concerns here, in my opinion: Think carefully about the above factors when making your decision.
My boss is a big fan of buzzwords and he insists that we should create our new website using Symfony 2.
I have already used Symfony to develop several apps, but the problem I encounter now is that this website consists of several apps, static webpages and even good old PHP apps consisting mainly of spaghetti code.
Would I need various installations of Symfony, one per app or can I
use the same? Would I use bundles for this, or is there a better way?
Does it make any sense to serve the static webpages using Symfony?
If I install Symfony on the root of the site so that I can use it to create a common login system, can I instruct Symfony to ignore the requests to the old apps?
Just like you suggest: for the apps I would use one Symfony installation and then a Bundle for each app
For the sake of coherent integration I would serve the static pages from Symfony, perfomancewise this doesn't make any difference, since they'll be served nicely from Symfony cache. As of Symfony 2.2 integration of static pages is also pretty straightforward done by the FrameworkBundle:Template:template in the routing configuration of your bundle. (e.g. see here: http://symfony.com/blog/new-in-symfony-2-2-cache-support-for-static-pages)
As for the requests for old apps, I should think that these would best be caught and redirected to the new corresponding apps whilst rewriting the params according to the needs of your new apps. This would probably be done by htaccess.
First of all, build some kind of test harness around all the pages that work today and should work afterwards.
If the whole website is being served off the same domain or you're sharing entities or some other configuration, then definitely use one installation of Symfony. You don't want to be updating multiple installations, or manually pushing data from one database to another. If they're on different domains, and you want each user to have only one login, use SSO.
Look at your traffic for whether to serve static pages through Symfony or not. If you get 1000s of concurrent users, and 80% of the traffic is to those static pages, then I'd say be pragmatic and server them from a CDN. On the other hand, if your traffic is a bit lower or more spread through the dynamic content then it would be easier if everything was in Symfony.
You can either block or forward the URLs, though it would be better to do it through the webserver if possible (Apache, Nginx), as loading the whole Symfony framework just to do a redirect is pointless.
I agree with bouscher. You can each distribute your apps into bundles. Using Symfony for static pages doesn't hurt at all especially that you will stick on using the framework for the apps, its better to keep it intact all in one platform. For the static pages you can create like a bundle that contains nothing but "views"(your static pages) using twig. Just create some routing rules then you'll be fine. Thats what I did with mine.
Will you rewrite your old php apps? or just tweak it a bit to be somehow symfony friendly?
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.
Disclaimer, I am technical support and sysadmin for my company, not a developer. I'm not after the specifics, simply an idea if what I'd like to acheive is possible or not.
We host hundreds of instances of our in-house classic ASP legacy ecommerce software application and due to countless customisations by clients and ourselves, version management is nightmarish, custom code can't be managed and we've given up releasing new features and mass deploying bug fixes due to the inability to track who needs what patches where.
Parellel to this question I am making management scripts to better automate this though.
What however I'd really like to do is using the miniumum possible effort, port the application code (not the database) to a single code base. Questions I have:
Can ASP relatively effeciently handle connecting to different databases depending on the host header being called? I plan some basic extension to the routine, get hostheader
lookup up db credentials in metadb, set application connection string accordingly logic.
The application writes a few files to the webserver from the database for caching purposes, I'd like to handle this by emulating this behaviour by writing it to something like /masterapp/customer1/specificfile.htm then changing the references to /specificfile.htm in the code to more like /masterapp/shop name/specificfile.htm. Obviously the routines that write specificfile.htm would write to the new location accordingly. Does this seem reasonable?
Other webserver-bound store specific contents like images and csv files I need to keep working without URLs changing ideally, can ASP employ logic to redirect get requests for /images/example.jpg to either /masterapp/shop name/images/example.jpg or /shopname/images/example.jpg depending again on host header? Or could that be done via isapirewrite? (which we already use)
I think these are the biggest challenges. I don't need a complete project plan of how to implement each of these things, I just want to know if it's possible. If the answer is 'yes' I should be able to sell my bosses on the development due to saving support time and our in-house developers could hopefully manage this.
This should be possible and I have achieved similar outcomes with code developed that way from the start. As you are retrofitting this in it's going to be a lot harder, but that's separate to your actual question.
To answer your actual points:
Presumably your DB connection string is already in a application variable or settings file? If so, you just need some logic in your global.asa Session_OnStart that reads the host header and selects the appropriate DB string. This could be hard coded or you could have a "control" DB that stores sites, their DB strings file paths etc and pulls the details into the session object.
This is related to the above, pull your cache storage locations from the DB, or have a "directory name friendly" base name for each site, so you can have "/masterapp/" & Session("strSiteBaseName") & "/cache/somefile.htm"
If you're on IIS7 then you can use the URL rewrite module to handle this, if you're on IIS6 there are 3rd party tools you can get to do URL rewriting for you. Again I have done this so can vouch for it working. If you want to get really clever, you can have your master app create the rewrite files for you and "touch" web.config to get them loaded into IIS.
One "gotcha" you'll have with host headers is remember to handle www and no-www records!
You mentioned custom code as well for each site, I haven't done this in production but have tested outside an app and you can rewrite functions after they've already been declared. You can't have includes with variable names, but you can load in a text file and execute it, so there is a way to have custom functions, or changed core functions specific to an individual instance of your over-arching app.