I need to design a content system similar to the news article 2sxc application. However, in my situation I have a primary subdomain and multiple secondary subdomains each of which is a portal in a single install of DNN. I need the primary to be able to selectively share articles with the secondary subdomains. I also need the secondary subdomains to be able to have their own articles. I have explored creating a ghost content type on the secondary sites, but this doesn't seem to share the content. I have used the visual query designer with an App Data Source to pull data from the zone and app of the primary. Using this, I can pull the needed article data, however, it also pulls lots of meta data like the name of each field on the content type etc. So I assumed I could filter this stream by content type, but when I do that it removes all items in the stream. Additionally, I have tried using razor code to get the correct data, but have been unsuccessful. So:
What is the best way to accomplish sharing the articles as described?
What am I missing on the visual query designer that is causing it to filter all results when filtering by type?
Thanks
If I understand you correctly, for 2, you are using the App Datasource. In the docs (linked), have a look at the first screenshot and the note above it. By renaming the streams coming out of the source, you automatically filter on the CT.
And for 1, I do agree that using Queries seems like a great choice.
There are a few more options to achieve this BTW
You can just show a module of Portal 1 on Portal 2 using Dnn features to share modules
Use the mechanics described by #Jeremy in his answer
2sxc 13.2 will offer a new shared-global-app system which is actually meant for other scenarios, but could also be used here.
You could also provide the data on your primary site as a RSS or WebService, and re-use that on the target site
Related
So I have a local website that I am developing and I was wondering if there is a way to create a blog functionality without creating a database and by using HTML5/CSS alone.
From searches around it doesnt seem possible, so maybe if I could embed the blog functionality from somewhere? i.e a blogging service that would allow my users to use my website but they are posting to a database somewhere else?
If I could do that, could you give me an example and what would be the method on doing it?
Thnanks
I actually haven't tried this yet, but you could have a look at http://developer.wordpress.com/, particularly in the API section. For example, if you look at the GET /sites/$site/posts/ API, the doc summary says:
Get a list of matching posts.
So one may use a query matching the pattern:
https://public-api.wordpress.com/rest/v1.1/sites/en.blog.wordpress.com/posts/?number=2
To obtain, in response, quoting the doc page, three parameters:
found (int), the total number of posts found that match the request
posts (array), an array of post objects.
meta (object), meta data
So you may create a free and simple blog on wordpress.com and access its post via the above mentioned APIs. Therefore, you won't require any database on your local site.
Still, some simple PHP, or maybe Javascript is required, but I really can't imagine how one could avoid preprocessing in any non static website, as a blog is. For example, you may use simple GET requests to use the APIs (see this doc as an example of how to do it).
Im really newbie with drupal 7 and I want to tests things with it:
I want to build a form page that will get information from users.
for example workes that input FIRSTNAME, LASTNAME ID, PHONENUMBER and etc.. after that they will submit and it will enter to the workers db.
as I mention im really newbie with drupal.
so first of all, where do I start? is form api is the best way to do it?
secondly, the system create the workers db or I need to create a new db and table?
Drupal has examples module that has lots of example for developers you can install it and check code how it, i think form_example it suite for you.
Why don't you use the standard Drupal Content Types. You can create a content type named worker and the have your workers add their info as you wanted.
To create your custom content type:
You can create your own custom content types by going to Menu >
Structure > Content types > Add content type
(admin/structure/types/add). You might do this as a way to organize
your content. For instance, you might have "Info" and "News flash" as
two simple content types on your site, rather than just using
"Article" for both.
Another alternative to use webform contributed module. It will give you the ability to create a from with fields of your choice.
Webform also provides few features out of the box you might need to use. Like; Limiting number of submissions and unique fields.
Finally, I'd suggest you can read Drupal concepts.
I'm trying to come up with some easy methods to share data between two Drupal websites. Here's my situation: Two websites both want a Top X Music listing with images, audio and data. One website is already creating and updating this list, and since they both use the same list the other website wants to straight up "steal" the first list, content, style and all. They want to take advantage of the work done to create the list on the other website. Their websites are structurally similar, and we control both sites. Audio is made playable using SWF tools.
Domain isn't really an appropriate solution here as the two sites share nothing besides the Top X Music list. I am able to create a view on the original site to feed the data in any format I want.
Some solutions I've been considering are:
Feed the data from one site to the other, hard link back to the other
site for audio/images.
iFrame the data on the site that is "stealing"
the list. (easy but seems too crude!)
jQuery AJAX load the data on the "stealing" site.
Basically I'm looking for suggestions of how you might handle this if they were your Drupal websites. I am familiar with Feeds, but would need to write a parser specifically for this feed, which seems like overkill for something so simple. Thanks! :)
You don't mention what version of Drupal you're using on the two sites. Assuming it's Drupal 6, you may want to check out the Web Widgets module and/or the Embed widgets module.
If you're just after a list of content from SiteA you could add a display to a given view and get RSS output. The ViewsRSS module gives you more control over what is returned.
If you're looking for more of a widget approach then I'd start looking at the Web widgets or Embed widgets modules. They're ok for basic functionality, but if you're looking to want more functionality I'd consider either embedding the content in an iframe (quick and dirty) or reviewing the services module(s) - although this may be overkill for your needs.
HTH.
I just want some opinions on what's the best way to go about meeting the following requirements.
I have
One main Drupal Installation
It is a typical "listings" site where users can list items
One user can have how many ever "listings" that are linked to his account
I want to be able to create sub-accounts, that use the same base site. However, for each subsite:
Only the users listings must appear on his site
It must have a completely different theme.
It must have its own menu items
The site must run off it's own domain OR subdomain
I need some answers:
Is this possible, or will each user need a completely new Drupal installation and just use a web service or something to get its listings from the main site?
What modules / components will make my life easier?
Any other suggestions to make this as simple as possible?
The problem description is not detailed enough to give a fully sound advice (and - additionally - it looks like you could probably get better advice on a drupal specific forum, as the question seems more related to installation and configuration than to programming), however - from what I understand - it looks to me that your solution could give in either of the two directions:
Tweaking a single installation to appear as different sites
Creating multiple sites that shares the same codebase and part of the data
The tweaking solution has the advantage that you have only one DB to mantain, but there is no actual real separation between the subsites. You could implement this by:
SUBSITES: mapping various subdomains on the same IP
CONTENT: using the native permission system to filter which list items to display (for example: each logged user can display only nodes created by himself, or set to be visible to its role, or having as associated taxonomy term its username...)
THEMES : if subsites will be used only by logged-in users, use the same mechanism that you would use for filtering content [each user can natively pick a different theme if you allow them to], if they must appear with a different look also to anonymous users, then use the URI to pick up the appropriate theme (if visitor X reaches the site via user1.example.com the site will have the blue theme, whilst if the URI is user2.example.com the theme will be pink).
The multiple sites solution has the advantage that you have a real separation between subsites (with even a different DB). But you would then have to either sync or transfer "on the fly" data between the main site and the subsites. If you go for this solution, you should probably take a look at the following links:
the services module, which allows to easy set up webservices
this page explaining how to connect drupal to different databases (surely faster than using webservices... reasonable solution if you for example have sites and subsites running on the same server)
I didn't want to stick this in a small comment but I am in agreement with mac on many of his points (upvote!).
The best way would be to create your subdomains and have them be symbolic links in the site folder to the default / main-domain folder.
Given what you have told us, you are much better off creating a module that creates its own node types (or even just CCK) and use a combination of the permission system (CCK offers this as well through content_permission), Views, etc. No need for separate sites, just need users to look at their own content.
The beauty of this approach is you can use Flag to allow user's to friend each other, use Views to allow them to see friend's lists, etc.
Theme's can be set on the account level, so no issues there.
"Have their own men" - does this mean have their own block on the sidebar or header than has customized links or a completely different menu SYSTEM? Will need clarification before I can answer that.
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.