I like the silverstripe CMS, especially the way how you can navigate through it when a dataobject has a 1-n or n-m relationship. However, I also like to navigate from 1-1 or n-1 relations (otherwise know as the has-ones :).
Now I have changed this field in such a way that I can show a link after the has-one dropdown, but I am still not able to point that link to the edit page of the dataobject referenced in the has-one. I can of course create a link manually (and I did), but this is not really a generic solution.
Is there a simple way to get the link to the edit screen of the dataobject in the CMS?
Related
I'm working on some drupal installation and googled the whole day, but I can't figure out an answer to the following question:
How is it possible to alter the admin/content page in a way that specific roles are only able to see or filter out limited content types?
Please notice that I don't want to restrict node access in general, I just want to make this page less confusing for editors with different roles and tasks.
I know there is the administration views module and there I can set filter fields in the way I want. The problem with this is that I'm not able to enter the views access restrictions and so all I can do is limit the view's content types for all roles.
Can somebody give me a hint how to solve this?
Thank you very much and sorry for bad english.
One way would be to make a custom module.
In this module you would create a page with hook_menu().
https://api.drupal.org/api/drupal/modules%21system%21system.api.php/function/hook_menu/7
Then in the page callback function that you create you load global $user and switch between the $user->roles, out putting different HTML lists of links depending on their role. If you want something a little more dynamic you can always load the various content types with node_type_get_types().
Then go into structure -> menus -> navigation and disable the default link, replacing it with the new page you created.
If you aren't 100% clear on how to do a couple of these things comment here and I will update my answer.
Ok, so I am attempting to implement the typical image-upload capability in my website. (I never expected it to be so complicated!!!) I finally found an AWESOME nuget package (MvcFileUploader) that uses the jQuery-File-Upload plugin. It works awesome, but I am having a little trouble figuring out how to associate this with my entities.
It is quite obvious how to create an Image entity when the files are uploaded. But then, I have many different types of entities that I would like to associated with the pictures after they are uploaded (e.g. news articles, blog posts, classified ads, etc.).
The way I have it set up currently is that I have the file uploader on the right side of the page and a form for a news post on the left. The file uploader does its thing and uploads a file, creating Image entities in the process. The problem arises when I want to then associate those new Image entities with my News entity. (Keeping in mind that at the time the Image entities are created, no news entity has been created yet.)
The first solution that came to mind was use AJAX to stick a hidden field into the news item form to represent the new image entity id. However, unfortunately, I can't seem to figure out any good way to make this work since I don't have easy and understandable access to the MvcFileUploader code to try to make it do such a thing.... and it works so well right now I am frightened of screwing it up. :) (It is a minified .js file.) (If anybody knows how I could do that easily and cleanly without screwing up the file uploader plugin, I would love to hear about it.)
So, my next idea is that I could create another type of entity whose sole purpose is to connect the Image and the news item together. What I would do is create that new entity (call it XYZ) when I output the forms and put a hidden field in both the news item form and the image upload form (since the mvcfileuploader provides the capability to output hidden fields into the form to be uploaded with the file-upload request). These hidden fields would each contain the ID of the XYZ entity for this particular news article. When I created the image entity, I would put its ID in the XYZ entity to wait for the News Item to retrieve when it is created. I think this might work, but it feels extremely messy. I don't like the idea of having another entity just for this purpose, and after the News Item is created (or the user simply leaves the news item creation page) I would still have those entities in my database. I would have to go clean them out regularly or something.
I also thought about simply making the News Item when the Create page was outputted and outputting the News Item ID into both forms... but then I would have to forgo any sort of required fields and other constraints on the news item fields AND I would have empty news items if the user left the page before finishing. Messy too.
Somebody help please :).
I would probably separate the views. The workflow might be for example:
News Create page without file uploader
The form gets posted to server and News created in database
Immediate Redirect to Details page for this News item with File uploader on right side
File Uploads are now always related to an existing item and can be associated with it
That's with the idea in mind that a News item makes sense without uploaded files, but an uploaded file doesn't make sense without News item. I don't know if that is a feasible assumption for your project.
For the user you could indicate on the Create page that he can upload files in a second step, like: "Please enter the information for this news item. Note: You can upload related files after the News has been created." Or so...
Is there anywhere online where one can find how to create custom blocks in the same way we can create custom content types in Wordpress. The desired result is to add a block that will allow the user to add/edit custom fields like client name, portfolio description, portfolio thumbnail.
I've created a free tool called "Designer Content" that lets you easily generate these custom blocks:
http://www.concrete5.org/marketplace/addons/designer-content
That being said, it is important to understand this key concept: In Concrete5, everything revolves around PAGES. In general, you want to try to establish an architecture where each piece of data is represented on its own page (a "details" page, which would roughly equate to a single blog post in Wordpress). Then you use the Page List block (usually creating a custom template for it to modify its look) to list out titles, links, and excerpts/photos from each of those "details" pages on a top-level "index" page (roughly equivalant to the home page or category archive in Wordpress).
For example, if you're building a portfolio site, you might want one top-level "Portfolio" page that shows a thumbnail and title of each piece, then a "Portfolio Item Detail" page type that contains one piece per page -- each living underneath the top-level "portfolio" index page.
The benefits of this approach are C5 gives you out-of-the-box tools to manage your "data" (pages) in this way -- users can add, edit, delete, and rearrange the pages via the "Sitemap" in the dashboard. Site search works without any modification -- each page (i.e. portfolio piece) will be its own search result with a link to a specific page. Also you then have more fine-grained control over access permissions if you ever decide to restrict access to only certain groups of people (registered users, etc.).
If you take this approach, you might find the "Page List Teasers" addon helpful (it will let the Page List block -- which you're using for your top-level "index" page -- to show actual content excepts from the pages instead of just a separate "description" field):
http://www.concrete5.org/marketplace/addons/page-list-teasers
Or if you want to dive deeper and customize the page list template even more, I have a starting template with a ton of code comments in it explaining how to do different things here:
https://github.com/jordanlev/c5_clean_block_templates/blob/master/page_list/view.php
But... if you're only talking about small amounts of information and you think a separate page for each one is overkill, then the Designer Content approach I linked to first will work just fine.
You can find a HOW-TO on creating new blocks written by Franz Maruna on the concrete5 website.
Here is the link: Creating a New Block Type
There is also a simple block you can download and install to help you follow the developer tutorials. You can find that here: Simple block template
I have created a page view using field style to display a list of teasers as I want. fields configuration in views allows us to link the field to it's node. but what if we have created view for node detail page and want field to link to it's relevant view.
I had the same question, and after a bit of research this is what I've concluded:
The views module isn't intended to replace a default node view. I say this because of the level of difficulty involved in doing this and the lack of information on how to accomplish this. Ryan Weal has posted a way to accomplish this by editing your node template that doesn't look too difficult to accomplish, and here is the link.
However, it seems that a more popular solution, especially if you are like me and don't like to get into editing theme files. You can use the Display Suite module to effectively reformat the default node content as you would like.
I'm not sure if I understand you properly, but it sounds like you are wanting to display a view in a page view of a node?
In order to do this, you could:
create a small module, using hook_nodeapi() or one of the D7 replacements for this function in order to insert the output of the embedded view into this page's content, by conditionally adding a $content element when the node is of the appropriate id
or (easier, but requires allowing input type PHP) embed the view right on the page.
http://thedrupalblog.com/embedding-view-drupal-6-using-views-embed-view for information on embedding views
After only a few weeks of working with Drupal I've come up with a recurring problem, which I don't really have an optimal solution to, so I'm hoping that someone here might be able to give some best practice pointers.
What I have is a region inside my node.tpl.php, which is populated with blocks that display content from two different CCK fields of the type node_reference. This works fine when displaying a single node. The problem appears when I need to use a view.
For example, lets say I have a news listing, and a single news item view. When I display the single news item I can use the news node node_reference field to reference whatever material I would like to have in my sidebar, but when on the news listing view I would like to reference nodes separately. What would be the best practice to solve this?
I'm having a few ideas, but none seem like the logical choice, how would you do?
My understanding of your problem is that you don't want the blocks to display on the view page and you want the block information displayed inline with the node.
The first part is easy, you can modify the block visibility settings to not show up on the path where you have the view.
The second part will depend on how you set up your view. If you are using fields you can simply add fields for the node_reference and they should display. If you are using a node view, you will have to override the template and create a template which displays the node reference field.
If you want further explanation please comment and I can clarify
After reading my question I realize that it was explained pretty badly, so I'll try again, and also tell how I solved it.
The Problem
On normal "pages" (when displaying only a single node), I have a sidebar that shows something similar to banners, which are either random, or I can select one or many that should always be displayed on the sidebar. This is solved easily when displaying a single node, using a CCK node_reference field. The problem is when using a View that displays multiple nodes, for example a news listing-
The Solution
In my case I could solve this by creating additional fields on my default Page content-type. These fields were called view, display and arguments. In my tpl.php I then embedded the news listing view inside a page, lets call it News. This way I gained great flexibility, and also helps the News page to know where it is located in menu structure.
Final comments
I have yet to discover if there are any drawbacks or dangers in doing this way, but if there are, feel free to share them with me :)
I tend to want to create my own modules, which create blocks and reference the database directly. Then I put the blocks inside of panels, this seems to be more flexible for me than using views and cck fields etc ...