Is there a FB Wall-like module for Drupal 6x?
I'm looking for module which will list all comments, privatemessages and other actions done around user account in a short table.
I would like to avoid using views (heavy!).
Some useful thoughts:
http://groups.drupal.org/node/17847
I would actually use Views as often os possible. It's one of the top modules for a reason. FOr you wall, you should combinate it with Panels.
If you realy want a avoid views, you should create different page regions that hold different parts of the wall inside them (but again, Panels already are capeable of creating something like this).
Related
Is there a module for Drupal that searches the final versions of the rendered pages (in the same way that Google would, for example) instead of all the nodes? The way I have set up my site involves views that display several nodes depending on what the page is. I don't want to search through each of the little boxes, but the finished version of the page instead.
For clarification, you are searching for a way to index the dynamic view content, and keep the search index out of the individual nodes?
I think your best bet is https://drupal.org/project/search_config
A lot has been added to Drupal 7 core, so that many 'search restrict' modules are now obsolete.
If this is still not what you are looking for, and you feel a bit adventurous, you can find various guides from before this was incorporated, and go the way of custom code. http://www.lullabot.com/articles/hiding-content-drupals-search-system
http://www.acquia.com/blog/drupal-search-how-indexing-works
If it is slick and stable, submit it back to the drupal community. They will be your friends.
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 have been looking all over for this, but so far without any luck. Is there a way to have comments per field instead of per node in drupal? If there are no modules available for this, do you think it would be hard to implement?
I thought I could make a "pseudo-content-type" with views that's nothing more than several content types displayed one on top of the other, so you could comment any of them. But then I don't know a way of making the user create all those content types at once.
The built-in comment module is not going to do comments per field on a node. I've been drupaling for almost three years and I don't know of any module that allows comments per field.
It is possible to do, but it would take a custom module and plenty of slick programming to get it to work. As far as difficulty I think an intermediate PHP developer with some knowledge of Drupal should be able to whip this out.
A kind of quick solution would be using panel module; form all your commentable content in nodes ad put them together all into a panel. This is kind a quick and static solution, possibly with views one can make it more custom.
I'm migrating a site from a proprietary cms (reddot) to drupal. For all its flaws, reddot has a very simple yet flexible model:
templates consist of markup with placeholders for variable content
every piece of content, from a full page, to a shared piece of sidebar content, and even a single image can be built from a template, if an appropriate one exists
My first impression of drupal is: woah, this is complicated! Rather than three simple objects, now i'm dealing with nodes, pages, blocks, regions, views, panels, etc. What is the simplest way to recreate the template/content/placeholder model that i'm familiar with?
Reddot uses a rather well architectured MVC-alike system. In addition, from my limited experience, Reddot follows the there is only one way to achieve Foo-philosophy.
Coming to Drupal, especially as a frontend-developer you will be dissapointed, lose a lot of hair and probably curse a few times when you realise everything has to be done all over again.
Coming to Drupal you will love the gigantic amount of (unfortunately unorganised) documenation and its flexibility and enormous amount of new posibilities.
When people come from properly architectured systems into Drupal, I advice them to do one thing: become pragmatism-exstremists. Don't (ever) try to make things proper, clean or well-thought out. You will only be able to do that once you truly grok Drupal. And that only comes with a lot of experience. Just fiddle untill it works, close the code and never look at it again.
First thing you will need to learn, is Drupals PHPTemplate engine, which is rather different from Reddots, but has a lot of similarities. Where Reddot uses RenderTags, Drupals PHPTemplate uses plain old PHP.
<%!! Context:CurrentPage.Template.Name !!%>
becomes
<?php print $name ?>
And yes, $name is entirely globally scoped. Remember? I told you to be a pragmatism-extremist. Don't even think about namespacing, object scoping and such.
Want to know what variables you have available? Just do a <?php print get_defined_vars() ?>.
Want new variables in your template? You need to preprocess them.
Want to change, alter, strip or modify existing variables? You either need to preprocess, or template override or even write new modules that make new or different variables available?
Knowing which to choose, when to preprocess, when to create modules, when to override, when to implement hooks to alter stuff is experience.
Drupal has never thought that out clearly, there is no general rule or best practice, other then the last eleven times that Foo-concept did not work out, maybe Bar proves the best.
Drupal's templates are similar to what you describe of reddot, but there are probably more options and they can be nested. To get a good sense of how the templates work together download the Theme Developer module and watch the associated screencast.
To get a sense of the "placeholders" you can use in a given template, visit the api.drupal.org page for the template file or check out this Drupal 6 Theming Cheat Sheet.
Another one bites the dust.. ;)
Let me know how you go with the migration Bobby Jack.
I think for the content you might be able to create an XML variant in the CMS and export everything to re-import it to Drupal..
On the Drupal note: Once you get your head around the concept of templates being able to inherit/being overwritten it's easy.
It's like a set of pre-assigned content classes in RedDot which can change to render them in a different layout. Similar to the "replace content-class" functionality.
Three associates and I want to integrate our individual Drupal websites so that a user can move fairly seamlessly between them. We're all new at Drupal, so our planned approach avoids "doing it the right way" by combining modules and database tables.
Rather, we plan on simply having each site's menu system include links to the other sites, and load the selected site via Iframes so that the overall user experience is more like that of a single, integrated system. We'll adopt a common theme for all sites, and pass the user id through the HTML call (and then process it via normal Drupal code) to avoid the need for more than one logon.
What are the negatives of this simple approach and are they so severe that a more traditional site-integration approach should be used?
To be honest, that sounds like a rather nasty can of worms you're looking at opening there. The mere mention of IFrames has me shuddering!
It seems to me like you'd be better off simply having one Drupal instance, with you and your associates as different content authors on the same site.
If you're looking at having the same theme across the three integrated sites, how will the users know which one they're on? And if the aim is to tightly integrate them, why not have the four of you simply contribute to the same core site?
If I had to make the decission, I would use the drupal multisite feature. You can even use the "single sign on" module to get all your users logged in to all sites. It is a bit of work, but I think it is well worth it.
Once you start throwing things into frames your users/visitors will loose the ability to bookmark the correct page. For example, if they find a page they like and book mark it, they will get 'www.site.com/index.php' rather than 'www.site.com/article/article.php?Id=12345'. When they come back, they'll be getting the default page of where the frame lives at rather than the expected page.
Since all three of your sites are based on the same data scheme, it would probably be better to 'do it right' the first time around rather than hacking something together that in the end will cause more headaches than solutions.
Good luck on your project and hope this helps some.