I am trying to create a site that will enable users to publish their projecs and enlist other people to join their project.
A user should be able to list a project, specify certain attributes (name,description, etc..).
There are few things i'm having trouble with.
First, by default publishing content is refered to as "content", i dont want a user to "add new content" but rather to "list new project".
Second, a project should have certain attributes, some optional and some mandatory, rather then the default title and body,
users should later be able to filter by these attributes when searching for projects.
is there a way to define the structure of content?.
Third, a user should be able to apply to a project, if he applies, the owner of that projects should receive the appliance, and accepte\reject.
In case he accepts, the users profile should be added a record that he is part of that project.
I am completly new to Drupal, and CMS in general.
My main expertise is with java, and I initially thoght about building the site with a java REST api in the backend and angular js in the frontend, but I have 0 experience with security and dodn't know how to do the user authentication and session management.
So I am currently trying out Drupal.
Is Drupal the right solution?
If so, how should I approach the requirements specified above?
Drupal (assuming that you are talking about version 7 since 8 is still in beta) is pretty powerful CMS, with a lot of (free) modules allowing it to expand it's possibilities.
When you are in back-end under Structure -> Content types you can see all available content types defined. There is also link "Add content type" which you can use to define your own. That basically means you can add any fields in any types you want. If you don't see the field type you need there is a big chances that there is a module which adds that field type so you just have to install it. You can also remove body (hide it actually), but title must remain (but you don't have to show it on front-end).
There is a "node reference" field type, but you have to install a module for it: https://www.drupal.org/project/references
So you can create dependencies you like.
And that "add new content" is just a link - you can create your own, set title as you like, just keep the same path. You can also set different theme for (some) admin pages if you want them to look differently. Under Structure -> Menus you can even edit admin menu, add new link and stuff..
Drupal is a bit heavy on resources, because of it's complex structure and database abstraction. For static content just turning on (built in) caches will help, but generally adding some additional caching mechanism won't hurt.
Related
I've been reading about building an intranet site with different frameworks and I've found Open Atrium to be a great alternative since it's naturally oriented to that use.
I'd love to add some custom workflows associated with personnel management, for example, each team member gets a reminder every Friday to fill out a form with the hours of the week dedicated to each project. Once submitted, the role 'administrator' gets notification of all the forms received and of those not received, the details of each one and the sum of hours per
project. Any insight on how to proceed with this implementation would be greatly appreciated.
I've searched but haven't found a module that has this kind of workflow. How would this be implemented with cck, views or fields?
I would use the Rules module to create the first part: emailing users to remind them to fill in their forms. The rules module has a 'Send mail to all users of a role' action which you can use.
I would use the Views module to create a new view of the filled in forms (which I assume will just be nodes of a certain content type) and make that view accessible only to the administrator in the view's 'Access' section. Views are quite powerful, and you'll probably be able to do most all of what you require with them, but it's hard to be more specific without knowing which version of Drupal you're using and any more details about the problem (such as, will this form users are filling out really be just a node or a webform?). As an example of a views feature: if you go to add a field to your view, you should be able to see a ' Global: Math expression' field, where you can do things like add previous fields together, etc.
On the other hand, if you use the Webform module to build the form users have to fill out, that can send an email automatically each time it's submitted and the responses can be downloaded into an excel file by the administrator to manipulate further.
Hope some of those ideas help!
We have many (hundreds) of clients that require basic, content-oriented websites. We are currently using simple WordPress deployments for these clients, but would like to make things more simple.
Is there a tool that exists that will let us white-label, or "re-use", a basic WordPress website and simply injecting some text and images into it to create a whole new website?
The process would look something like:
1. Have new client that needs website
2. Gather some client info (phone number, images, biography, etc.)
3. Inject this info into a previously created WordPress "template" site
(we would use the same template for all clients)
4. Pick a WordPress theme
5. And done. We now have a rebranded WordPress site for this client with minimal work
done.
Step 3 is where we need help? Is there something that already exists that can do this? If not, what is a good method to do this "injection"? We were thinking just creating a small app that would go through the template WordPress site and do a find-and-replace.
Perhaps it would be good to simply write a plugin which would allow you to gather exactly what info you need in a settings panel there, then inject the information into whatever theme you're using from there.
So it would be a relatively simple step as you create new sites to install the plugin, use it to add information, etc. (Perhaps if most of it is client information, it stores the information with admin user information).
Well if you want to be able to re-use your branding, you could do them in your theme's function.php, so its kind of "portable"
For example, when I re-brand a wp site, and customize their wp-login. Change logos and stuff.
and things like, hide menu of theme-editor, plugin-editor, etc
all goes together, and I put the codes in the functions.php
I'm trying to create a simple module to preview themes in Drupal. Each user has their own custom node and I want to be able to show them a preview of how the theme will work without them actually enabling it. Right now this is what I have:
function theme_preview_info($new_theme, $node_id)
{
global $custom_theme;
$custom_theme = $new_theme;
$node = node_load($node_id);
return $node->body;
}
It will display the content of the node, but the formatting is all messed up. How can I properly display the node exactly as it would as if i went to node/1, but instead view it at theme_preview/theme_name/1?
Do you have any experience building Drupal modules?
If not, you may find that what you are trying to do is not all that simple.
You will need some interface for the user to choose which theme they are previewing. Then, you will need to hook into Drupal's routing to direct users to the appropriate node using the selected theme preview based on a customized path alias (theme_preview/theme_name/1). There's most likely a lot of other back-end overhead that I'm not anticipating at the moment.
If you have experience with building Drupal modules, though, that might not be a big deal.
Switching out the theme is probably the easiest part. If you're in Drupal 7, you can use an implementation of hook_custom_theme() to change the theme used for particular nodes based on your intended criteria (i.e., which theme the user selected).
http://api.drupal.org/api/drupal/modules--system--system.api.php/function/hook_custom_theme/7
This way, you can actually allow Drupal and the selected theme to completely handle the rendering of the page, giving a more accurate preview.
I'm not sure how exactly you would go about creating the user's theme-switching interface or routing the user to a specific path alias for each theme selection.
You also might want to look into the ThemeKey module (http://drupal.org/project/themekey). It's possible you could use that module somehow to simply set up ab version of each node to be viewed in each different theme.
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.
I'm trying to find a simple solution to a specific problem, which is a way to allow bloggers on my site to be able to control permissions on individual posts. So they could decide whether to have their post show up for all visitors, or for authenticated users only.
The closest module solution I've found so far is the Node Access module. It comes very close, but it doesn't quite do it for me, in the sense that it creates a new "grant" tab to the content type, then displays checkboxes with too many permissions options (allow a role to view, edit and delete), where I only want to display the view option, and I need it to be located right on the content edit/create page, not in a separate tab.
Unless I can find an alternative simple solution, I'll have to add a hack to the blog module or something. I can't think of any other way to do it.
Any ideas?
If you want to avoid coding and keep things simple, there are a couple solutions that come to mind.
TAC Lite allows you to associate a vocabulary with an access control schema. Each term can be associated with different view/edit access permissions for specific users or roles of users.
In this case, you would want a single term in the configured vocabulary. Set it up so that this term ("Restricted Access") when set, limits access to authenticated users only.
The advantage of TAC_lite is the flexibility of building out your access model as new requirements show up- such as having "premium subscribers" gaining access to even more restricted content.
Content Access allows you to set access control rules by content type, and override by node. I can't speak to the UI, as I've not used this mode.
In case Graysides (good) suggestion does not fit, you could do it yourself without 'hacking' the blog module by implementing hook_nodeapi() and hook_form_alter() in a custom module:
On the hooks 'load' operation, you could add a check for the nodes current access settings concerning anonymous vs. authenticated users. You'd add a property for that to the node object (be aware of potential naming clashes - you should prefix the names of custom properties in the node object with your modules name).
Via hook_form_alter(), you'd add a form element (e.g. radio buttons) to the node edit forms for your blog nodes that allows users to select the visibility, defaulting them to the new node property from above.
On insert and update operations of hook_nodeapi(), you'd then check the new property again and adjust the nodes access settings accordingly.
Note that this approach would possibly interfere with other node access module actions, so it might need some refinement. I do not recommend it - I just wanted to suggest an alternative to 'hacking core'.