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.
Related
I've never worked with any CMS and I simply wanted to play with such ones. As originally I come from .NET roots, so I was thinking about choosing Orchard Core CMS.
Let's imagine very simple scenario, together with my colleague I'd like to create a blog. As I'm used to work with web based systems and applications for a business for me it's kinda normal to work with code repository, having multiple environments dev/test/stage/prod, implementing CI / CD, adjusting database via migrations or scripts.
Now the question is do I need all of this with working on our blog with a usage of CMS.
To be more specific I can ask few questions:
Shall I create blog using CMS locally (My PC) -> create few articles and then deploy it to the web or I should create a blog over the internet and add articles in prod environment directly.
How to synchronize databases between environments (dev / prod).
I can add, that as I do not expect many visitors on a website I was thinking to use Orchard Core CMS together with SQLite. Also I expect that I can customize code, add new modules, extend existing ones etc. - not only add content (articles). You can take that into consideration in answering the question
So basically my question is what should be the workflow of a person who want to create / administer and maintain CMS (let it be blog) as a single person or as a team.
Shall I work and create content locally, then publish it and somehow synchronize both application and database (database is my main question mark - also in a context how to do that properly using SQLite).
Or simply all the changes - code + content should be managed directly on a server let's call it production environment.
Excuse me if question is silly and hard to understand, but I'm looking for any advice as I really didn't find any good examples / information about that or maybe I'm seeking in totally wrong direction.
Thanks in advance.
Great question, not at all silly ;)
When dealing with a CMS, you need to think about the data/content in very different terms from the code/modules, despite the fact that the boundary between them is not always completely obvious.
For Orchard, the recommendation is not to install modules in production, but to have a dev - staging - production type of environment: install new modules on a dev environment, test them in staging, and then deploy to production when it's safe to do so. Depending on the scale of the project, the staging may be skipped for a more agile dev to prod setting but the idea remains the same, and is not very different from any modular application.
Then you have the activation and configuration of the settings of the modules you deploy. Because in a CMS like Orchard, those settings are considered data and stored in the database, they should be handled like content. This includes metadata such as the very shape of the content of your site: content types are data.
Data is typically not deployed like code is, with staging and prod environments (although it can, to a degree, more on that in a moment). One reason for this is that a CMS will often feature user-provided data, such as reviews, ratings, comments or usage stats. Synchronizing all that two-ways is very impractical. Another even more important reason is that the very reason to use a CMS is to let non-technical owners of the site manage content themselves in a fast and direct manner.
The difference between code and data is also visible in the way you secure their changes: for code, usual source control is still the rule, whereas for the content, you'll setup database backups.
Also important to mention is the structure of the database. You typically don't have to worry about this until you write your own modules: Orchard comes with a rich data migration feature that makes sure the database structure gets updated with the code that uses it. So don't worry about that, the database will just update itself as you deploy code to production.
Finally, I must mention that some CMS sites do need to be able to stage contents and test it before exposing it to end-users. There are variations of that: in some cases, being able to draft and preview content items is enough. Orchard supports that out of the box: any content type can be marked draftable. When that is not enough, there is an optional feature called Deployments that enables rich content deployment workflows that can be repeated, scheduled and validated. An important point concerning that module is that the deployment only applies to the subset of the site's content you decide it should apply to (and excludes, obviously, stuff like user-provided content).
So in summary, treat code and modules as something you deploy in a one-way fashion from the dev box all the way to production, with ordinary source control and deployment methods, and treat data depending on the scenario, from simple direct in production database instances with a good backup policy, to drafts stored in production, and then all the way to complex content deployment rules.
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.
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.
I'm thinking about attempting to design a new framework architecture aimed at allowing a web app to later be easily ported into a system such as Drupal or Joomla while maintaining the independence of the original app such that updates to core functionality would require only one release or otherwise minimal extra work.
Before I start on this however, I would like to see what work has previously been done that comes closest to what I am proposing. So an answer to this question would come in the form of a reference to the most similar work or if possible a definitive 'no' that this has not been done before.
Clarification by example: MediaWiki is a common web app that has become one of the most highly recommended of its kind. However, site admins building their sites with Drupal would be required to hack MediaWiki in order for it to play nicely with Drupal in terms of sharing a user base for example. Imagine that MediaWiki has decided to do a complete rebuild of their system, what design could be used to make this interaction simply require a Drupal module or Joomla component and thus make MediaWiki available to more users?
I'm using MediaWiki as just an example, I think modules and components already exist that solve this particular problem but I hope I am able to get my idea across. It is a problem I have encountered many times during web development now that CMS systems are appearing more and more enterprise-like.
Thanks!
godwin
Content Management Interoperability Services (CMIS) is an OASIS Specification that you can use to imrprove the data portability and interoperability of a CMS. If your system has (or your provide) a CMIS interface, you can move content to / from other CMS systems that also provide CMIS interfaces.
See:
http://en.wikipedia.org/wiki/Content_Management_Interoperability_Services
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=cmis
*This is more of an architecture level question.
I am new to DNN development , we are trying to build an e-commerce site which will showcase all the products which will be tied to our current order database.
Am I wrong in assuming that any custom development that I do via DNN would be in MODULE form ? I created few custom module (i.e. list of products) which would tie to database in code behind and display data from SQL. This seems to be very heavy approach if I have to make modules for every functionality.
Is there a better way here ? Can I (is it recommended) to directly change the DNN pages to accommodate this type of functionality ?
UPDATED
Is it possible to do development without moduels ? i.e. provide code right in the html text editor or something. If i create new module from DNN template then it adds many files ....that is why it feels heavy
It is strongly recommended that you not directly change DNN. This will make it very difficult to apply upgrades to DNN and cause headaches for whoever maintains the site after you.
The main extensibility point in DotNetNuke is the module. The module is just some executable controls that you can place on any page. It shouldn't be significantly heavier than any other approach you would take. Whatever you want to do in DNN itself, you should be able to do in a module, and just place the module on a page.
You could also potentially have some of your functionality in the skin, rather than the module, if that is easier or makes more sense. Generally, the skin has functionality that is shared across most pages in the site, and module are used to place specific content on specific pages.
If you're looking for something simpler, you might try using the core reports module, which will allow you to style the results of a query from the database (if you don't need the interactivity that a module would provide).
Your good options are as follows
Build a separate Web Application for your e-commerce, but provide heavy inter-linking with the DNN site. With this method, DNN would be used for content.
Purchase a third party e-commerce module-set like SmithCart and try to configure it to meet your business model
Build custom DNN modules
Our current project utilizes option #3. We have 25,000 products and about 3,000 product listings with heavy customer-customization functionality.
While it might seem heavy, as in, a distinct module project per section of e-commerce, it doesn't have to be too complex.
Example Modules:
Product Listing
Product Details
Shopping Cart
Order Checkout (we split this into 4 modules)
Search Module
Search Results Module
You can use URLRewrites to map all your products to the same DNN Page/Module.
As a result, we really have very few non-content DNN pages.
In summary, it might feel a bit heavy, but with the proper design it can go rather smoothly in comparison to a separate web app.
There are ways to use existing DNN features without module development. You can do it by adding a sub application in your folder.
For example, you can look at http://www.firstphera.com/GiftRegistry/Index.aspx, FirstPhera.com is a main dnn application and folder GiftRegistry is a pure asp.net sub application that uses dnn's providers to deal with database. Custom implementation of registration and login was the only thing that was challenge, everything else working fine.
But If are building an e-commerce application, at long term you will get benefit from module development way.
It is not strictly necessary that you create separate complected module like you shown in screen shot. If you look at blog module, it has feature like latest blogs, search blog, archives etc are all implemented in single module.
It is also possible to create a single module with related features in dotnetnuke using the technique called ModuleDefinitions. Look http://lakhlaniprashant.blogspot.com/2010/04/dotnetnuke-what-is-module-definition.html.
I would strongly recommend to visit NBStore source code if you want to understand the e-commerce related module development in detail.
Please let know if you have any other question.