A customer of mines wants the ability in their Drupal site to set some variables which they will embed in content. You know, things like number of customers, number of branches and so on. This way, when they update the variable values, the changes ripple throughout the site without them having to go and update a bunch of pages.
Have any of you come across a module which can handle this?
Many thanks
Froogle.
Token combined with Token Filter - it's fairly easy to setup your own tokens and instruct your content managers on how to use them using the Token Filter module.
Related
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
I am facing an issue with wordpress. I have two sites. On the first site there is a form that takes inputs and stores values in custom fields to be later used for various calculations on that site.
On the other website, I need to access these same values from the first website and use them thoughout the second website in multiple elements. So I've come up with an idea that because those stored values on the first website are already being displayed (as in, they are in some HTML elements in a visible page), I could just get that first website content and than do one of two things:
Create similar custom fields in the second website, and write a function in functions.php that would take the values from the first website and update custom fields in the second website every time it loads, so then I could use those values throughout the second website (it seems to me that this is a stupid solution).
Write a function in functions.php (in the second website, the one that needs to receive the values from the first) that would create javascript variables from that first website, so that could be used to populate all the elements I need.
Maybe there is some much better solution for all of this. To be fair, this is the first time I am doing something like this, so you could say I am very unexperienced.
Is there another better solution for this? And if there isn't, which of the two solutions listed above is a better one?
Though there are many possible options and that may generate debates based on individuals' experiences and or prevailing conditions, you can easily achieve your intended goal by consuming data from your site one into your site two, then, apply whatever necessary logic and actions needed there (in your site two).
Using the latest version of WordPress, you can take leverage on the in-built REST API in order to access the desired data from site one within site two.
I've just started to learn symfony 2, and I have a small question
For example I have a site with articles. I want to show the total number of articles on every page, but every page is generated by some bundle.
So I need kind of some common script to do initialization of main variables, such as articles count.
How should I do it?
A simple way to achieve this is to have an action that fetches and outputs the total number of articles. You can then render that action from within other views (ex: $view['actions']->render('ArticlesBundle:Articles:getCount')). If you want this displayed on every page of your site, I would recommend rendering it from within your base.html.php view (or base.html.twig depending on which templating engine you're using). I'd also recommend caching it somehow, so you're not constantly hitting the database for a count that may not change very often.
See the docs on Embedding Controllers for more detail.
You can further expand on this example to define other 'main variables' that you want to use throughout your site. One idea is to define a service object whose purpose is to hold these variables, and then access its contents when you need to.
By the way, the title of your question is not descriptive of your problem, please consider rephrasing it.
This is my first time building a site with Drupal (7). I have plenty experience with LAMP, HTML/CSS and javascript, but I want to make sure I am doing things the 'Drupal way' before I start hacking together a custom solution unnecessarily. I've searched forums and modules, but have come up empty.
The site I am building will have different tiers of users: students, teachers, and parents. The difference between these users is:
The information collected during registration, and
The pages the user's have access to.
I think at least part of the solution lies with creating roles for each type of user, but it seems Drupal only has one registration page for all users. How would I create a different registration form for each type of user? What is the 'usual' way of assigning roles to users automatically?
I know this is late the game here but I thought I might refer people to the "Rules" module... Instead of thinking about this from the "user-specific" registration form perspective, think of it instead from the perspective that you still have only 1 form but with additional / optional inputs, whereby subsequent actions (rules) are then enacted upon depending on the values of said additional / optional fields.
You might also check this out, too:
how do i make diffrent registration form in drupal?
I'm just updating my answer as I see it didn't apply for D7.
I've just begun developing a D7 site with a similar request.
There seems to be a module which should fit perfectly, although I still have to try it:
http://drupal.org/project/profile2
Good luck with it.
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.