I'm new to Drupal and I had for the need of the client, to extend the functionalities of the Aggregator module which is part of the core of Drupal.
So as I've not found clear documentation on this subject, I have duplicated the module, changing its namespace to prevent any updates and done my stuff, adding new fields in DB, extend the Item entity, update Parser and Processor.
It's working...but this is bad practice. So I was wondering if Drupal offers natively (as it is based on Symfony) any kind of proper ways of extending Module Core/User.
Related
I am currently in the process of refactoring and restructuring an existing Symfony 2 application.
There are a few base templates and all other templates inherit from them. Right now, all the templates are PHP. I am planning to migrate the application to TWIG.
The problem is that this application is already in use and while migrating I am also expected to add new features to the application. This means I can not freeze the current state of the application, fully migrate to TWIG and then continue working with that.
This means that a migration to TWIG is only possible in small steps, i.e. I can only migrate a handful of templates before I have to deploy a new release. There will also be some new templates for the features I am adding and I would also prefer to add these in TWIG format.
My plan right now is to migrate the base templates to TWIG first and then include the existing PHP templates in those new base templates. Afterwards, I would continue migrating the other templates in small batches.
Looking at documentation online, it is possible to have both the PHP and TWIG template engines enabled simultaneously. However, I could not find any tutorials, examples or documentation mentioning that you could not only have those two engines side by side but also have templates from one engine include templates from the other engine.
Is there a way to mix templates from those two engines as I described?
Even if there are similarities between both engines (they still do the very same thing), they are working internally in their own ways, the architecture and the code are very different.
Templates provided in PHP are managed by the Templating Component.
Templates provided in Twig are managed by the Twig engine.
Have a look to both codes, and you'll understand why we just can't compare/mix them.
For example:
slots from php engine plays with string overwriting
blocks from twig engine plays with class overloading
So even if you were able to access the twig-compiled file using a tricky import, you'll not be able to overload a block by the simple fact that your php template isn't a class.
We have several Drupal 6 sites. On most of the sites we will have some content editors, who will optimally log into a dev/test site and create content. Mostly just plain vanilla pages. What is the best method for migrating these newly created pages to the live server? I know there is the Deploy module and also Backup and Migrate. Are these the de facto standards? I was wondering if there is anything else I might be overlooking or if there is a better/easier solution. I am ONLY interested in moving content. We will be using GIT to move code and the Features module to migrate admin changes.
THANKS
In the past I've used node_export and recently I've found (in drupal 7) that the uuid module is invaluable. It means you can keep a track of content even if the nid's change as you move it over.
There are some legacy modules hanging around too that did an okay job but their functionality has really been surpassed by the modules you mention and the ones above.
If you're creating all your content using fields added with cck, you shouldn't have a problem. I personally use node_export along with features to allow easy importing and updating.
One gotcha you might want to look for on node_export is when importing on the new site, if a node is found with the same uuid (i.e. you're doing and update), the default is to create a new node. I prefer to create a new revision. Worth tracking down that setting (it's there in d7 so likely in d6 too).
EDIT: node_export doesn't currently export panels very well if at all - just in case.
It depends on the structure and diversity of the nodes (how many fields of which type, how many node types). My first try would be to generate a view with XML output (views_datasource.module or views_data_export) on the dev site and use the feeds.module for XML import on the live site.
The above XML export modules are avalable for D6 and D7. In Drupal 6 I used views_bonus.module for the XML export.
*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.
I'm curious if a CMS like Drupal or WordPress is a suitable approach for creating a data-centric web application. It's nothing fancy, but would require a login to access, and essentially have search parameters, results pages, and detail pages. I can program this pretty easily but would prefer to just theme Drupal or WP, since I'm not much of a designer. Thanks for any insight, as well as any examples of where this might currently exist!
-e-
Sure, Drupal is suited for data-centric websites. Development Seed is a company that use Drupal and make data-centric websites but they also use other technologies such as Node.JS. As suggested by Marek Sebera, it really depends on your actual needs and what exactly your site will be doing with the data.
You basically have two ways to integrate your data into Drupal. One is to import the data into Drupal as entities (a generic concept for anything data in Drupal 7) or nodes (a concrete concept for anything content in Drupal). The other is to directly query an external data source from Drupal.
To import data, the Feeds module is a very solid and flexible solution. Out of the box it only supports CSV, Atom and RSS from local files or HTTP. But it is flexible and extensible and there is already many contributed modules that extends it.
To query the data, both external or imported, you can use the Views module to build query pages. For external data source support, you will need additional backends modules and probably have to write your own.
If you import the data as entities, you can also uses the core's EntityFieldQuery to write your own query without using Views. And you can also uses the Search API to index the imported data using a search engine such a Apache Solr.
How can we extend the Alfresco database? I need to add new tables to the existing database structure.
Does alfresco support this?
thanks in advance,
sri..
I think changing the alfresco db model is never a good solution. Some alfresco upgrades are made using Schema Upgrade Scripts, and that could get messy.
Have you tried to extend the alfresco content model?
Alfresco support some data types, allowing you to persist data. The Web Script framework allow you manipulate all your data inside your content model.
If your data is not suitable for a "content model", I think you should create a new database to hold your data.
Well, it is just a database. So you can create as many new tables as you want just like you would in any other database.
Obviously Alfresco won't use them because it doesn't know them, but you can query the tables as you like.
Advices from alfresco engineers are do not touch alfresco database. Please take a look at this page.
http://forums.alfresco.com/forum/general/non-technical-alfresco-discussion/where-alfreso-user-details-are-stored-i-alfresco
Changing alfresco database is not recommended.Content Model will be the good way.If such requirement is mandatory than,
You can use spring with hibernate for database connection.Properties which is required for connecting database are all ready declared inside alfresco-global.properties which is located inside "tomcat/shared/classes/".
For Spring bean injection you can declare beans inside any file which ends with "-context" which resides inside "tomcat/shared/classes/alfresco/extension" folder.
I will still recommend developer to use content model.
Depending on your use case, you may or may not need to play directly with the[/a] data base. I think your use case should fall in one of the following:
Use case 1:
You need to setup some metadata on folders and/or documents. You may have to nest multiple levels of nodes with different sets of custom metadata on each level.
You probably need to extend alfresco models in order to define custom document/folder models that best suits your business requirements. Please check jpotts' tutorial to learn how to do so.
Use case 2:
You need to define multiple lists with different sets of properties, those lists may or may not be linked to some content in your alfresco repo.
You probably need to learn more about alfresco sites' datalists, once you do so you may be interested in learning how to extend OOTB alfresco content model, jpotts' tutorial would be a good starting point, and then you should be checking this tutorial in order to learn how to manage datalists in stand alone aikau apps/share pages.
Use case 3:
You need to leverage a relational database in order to define and leverage you complex business logic that do not fall in any of the use cases defined above.
Are you sure you do not want to code a brand new app leveraging a technology that you are familiar with and have it communicate with alfresco using RESTfull api/cmis/.... ?
Are you sure alfresco is THE way to go ? If so, and you still want to have your custom complex business model in a bare relational database:
Please consider using a separate database instance / database for your custom extension, this way you would be sure any new patch/upgrade to alfresco that may change database structure won't affect your extension (or at least wont give you hard time upgrading it)
If you are really tied to only 1 database instance / 1 database schema, you will probably want to precede your table names with some prefix and hope none of alfresco future upgrades would have new tables with the same prefix. You probably also need to make sure to manage your database config wisely (connection pools ..) so neither your alfresco instance nor your custom extension have to starve. (make sure you close the connections you are opening)
Alfresco and Activiti come with a database. It is not good to access the database directly. Doing so can cause unexpected locking behavior or exhaust connection pools on the DB. This turns out into performance problems and other kinds of issues are possible too. In case you want to update Alfresco or Activiti you can do it through APIs. Easy to extend, easy to customize and hassle free integration capability are some of the reasons which has made http://loganwinson.doodlekit.com/blog/entry/4249216/top-things-to-know-about-alfresco-development>Alfresco web development popular among businesses.