The standard ("ships with Drupal") user page appears to be compacted into the $user_profile() array. Then, it's unpacked and "printed" (to the screen) by the somewhat terse user-profile.tpl.php template:
<div class="profile"<?php print $attributes; ?>>
<?php print render($user_profile); ?>
</div>
Is there a guide somewhere that would help me understand what the typical internal structure of this array is, and what hooks I might need to employ in order to place DIVs, classes and so forth into it, in order to achieve certain basic design goals?
Take a look at https://drupal.stackexchange.com/questions/88407/how-to-create-a-profile-page. I strongly suggest to use the Panels module. It allows you to add blocks, views etc. to your pages and makes theming a lot easier. There are tons of information about Panels on the internet, so I suggest you have a look around first. The following links can be a good start:
https://www.drupal.org/node/496278
https://drupalize.me/search?query=panels
Related
Summary
I'm implementing Schema.org JSON-LD structured Data into a React application that's very content heavy. I've got it all set up properly, but I'm questioning whether the way I set it up is best practice or acceptable?
The Question
I have tags minified throughout the body of my code within each element. I question this approach because it seems inefficient to have script tags all throughout the body rather than trying to consolidate them in the head tag under 1 big script tag with all the JSON-LD.
Example:
Let's say I have an eCommerce category with a lot of products on the page. Each product is contained in a <div>. Within each product div I'm providing a schema.org tag.
<div className="product-1-example">
<script type="application/ld+json">{"#context":"http://schema.org/", "#type":"Product","name":"3rd thing"}</script>
</div>
<div className="product-2-example">
<script type="application/ld+json">{"#context":"http://schema.org/", "#type":"Product","name":"3rd thing"}</script>
</div>
Here's a screenshot if the example above doesn't help of how the code is outputting:
Is this an OK approach? It just seems bizarre to me to have script tags like this all over the place? The problem I'm having as well is that because of my component structure, I can't really bundle up 1 nice tag at the top with all the consolidated structured data (i.e. grouping all the product JSON-LD data into 1). I could maybe build a script tag at the top with most of the data, and then fill out the rest with microdata?
The only way to really know is to test with the systems you want to read your markup.
There is no reason doing it that way is wrong. And I presume its done that way as its added at the point the system is processing those entities. Maybe neater to have each add their own script at the top instead of inline if possible.
I personally prefer to keep entities in their own scripts. If there is a bug in one, it will not stop the others from being parsed. You can have entities cross reference to each other by their ids.
Try not to mix with microdata. You can't cross reference ids between the two.
You probably also need to think about your entity structure. Typically you only want one main top level entity that represents what the page is about. Some other top level entities are fine as they are considered WebPage related, e.g. BreadcrumbList. But you don;t want to send mixed messages. e.g. if you mark up 10 products, which is the one the page is about? If you mark up a Product and Article. is the page an Article or about a Product?
I am currently trying to jazz up a SilverStripe site by making the content more engaging. The site is responsive, but all this means currently is that the navigation bar/header snaps to a more mobile friendly style when it hits the mobile break point.
The long and short of it is, my main page.ss is this:
<html>
<head>
<title>$Title</title>
</head>
<body>
$Header
$Layout
$Footer
</body>
</html>
With $Layout rendering a few variations of a basic page. We have a couple of layouts that aim to give our webmaster pages that are a bit more engaging - for example we have an accordion type page that has many accordion section DataObjects, that present the page as an accordion page with the open/shut javascript functionality.
But this is not enough. I want to give the webmaster more flexibility in the CMS to create interesting pages, without me having to create hundreds of different page types.
I'm thinking of creating a module that gets rid of the main $Content field for all pages, and instead inserts a sort of grid system management field. The webmaster can add rows (one DataObject) and then split those rows into sections (another DataObject). The sections will have a content field managed by TinyMCE, just like a page has. Then on the front end I will map these rows and sections to a responsive grid system.
For variations on the sections, I will add classes (a bit like having different page types) that render slightly differently. The sections will have .ss and .css (and possibly .js) to control their own look and feel.
My question is, how have other people approached this problem? Does my idea sound like overkill? Or does it sound like a good idea for a module?
-
For some examples of what I am trying to achieve, this page is a good example:
http://www.wingsforlife.com/en/research/
Content is split up into various sections, which allows for better control when the page is resized. Also throughout the site, content is varied, sometimes it will be in a single column, other times two, which snaps to one column when the window is smaller.
On the home page, if you scroll down, there are 4 links that are presented inside circles, that contain a number and some text: http://www.wingsforlife.com/en/
This is something I can't see being possible inside TinyMCE (which is fair enough as TinyMCE is just a basic content editor, not a web design tool).
Have a look at https://github.com/burnbright/silverstripe-widgetpages for an implementation of using Widgets to compose a webpage. Also https://github.com/g4b0/silverstripe-widget-pages-extension.
this can easily be achieved by replacing the HTMLEditorField that's linked to the Content field in the database by some GridField, managing DataObjects that make up what you might call 'ContentParts'. we've already used this approach in some projects to allow for more rendering flexibility of content elements.
simply tie some DataObjects to your Page class:
private static $has_many = array(
'ContentParts' => 'ContentPart'
);
then, use a GridField to manage them in your getCMSFields:
$gridFieldConfig = GridFieldConfig_RecordEditor::create();
$field_ContentParts = new GridField('ContentParts', 'Content Parts', $this->ContentParts(), $gridFieldConfig);
simplest way to render them in your template is as follows:
<% loop ContentParts %>
<section>...</section>
<% end_loop %>
of course you'll want to have different contentparts, so you might want to create subclasses of ContentPart with their custom fields and use the GridFieldAddNewMultiClass component to add them to your GridField (it's part of the GridFieldExtensions module, to be found here: https://github.com/ajshort/silverstripe-gridfieldextensions)
hth
First time poster here, I'm a designer not skilled at all with php and I have a small issue I don't seem to be able to solve. I'm making a site in drupal 7 using a sub theme on zen.
Btw this is a great CMS, even though people say it's really more a developers CMS. I have no trouble to do what I need using views, rules, display suite etc. So a big thank you for all the developers out there making this such a good CMS. But for this apparently simple problem... no module will help me (I think) and I'm kinda stuck.
So here it is: I'd like to add a subtitle next to the title in all my pages.
So what I did was to add a custom field into the content type basic page (machine name: field_sub_title) which is a simple text field.
I uncommented the following line in my template.php
function mytheme_preprocess_page(&$variables, $hook) {
$variables['sub_title'] = t('field_sub_title');
}
Now my question is how do I load the content of my custom field into that variable?
I know i need to change the second part, but I don't have a clue as into what I need to change this.
Displaying the variable into the the page.tpl.php is something I know about so I only need help with the first part.
{EDIT}
Ok I found how to do this :)
I was looking for a solution in the wrong place. I don't need to change any thing in the template.php file.
Just needed to add this bit of code into my page.tpl.php:
<?php
print $node->field_sub_title['und'][0]['value'];
?>
So I'm posting this here for other Drupal newbies struggling with this....
Your solution may work for now, but there may be a more Drupal-y way to handle a problem like this. If you haven't noticed any problems yet, you may find one or more of the following issues down the road:
Someone who doesn't know php or Drupal theming may need to change the way this works.
If you're like me, you may forget where exactly in code this was implemented.
You may see superfluous markup and/or errors on nodes (content) that do not have this sub-title field (ie. event content not having a sub-title field while basic pages and news articles do).
When you add a field to a content type, it will automatically appear anytime content in that content type is displayed. You should be able to add the sub-title field for your page, event or whatever else you need and have it automatically appear in the markup.
You can 'manage display' of a content type to drag and drop the order for fields to appear. You could take it a step further by using a module like Display Suite to add formatting or layout per-content type.
If you feel like this isn't good enough and the markup for the subtitle must be at the same level as the page title (which is rare), at least add an if statement to make your code check to see if the variable is present before trying to print it. I'd also add a new variable and comments for code readability.
<?php
$subtitle = $node->field_sub_title['und'][0]['value'];
if($subtitle){
print $subtitle;
}
?>
Consider using field_get_items or field_view_value, or at least use the LANGUAGE_NONE constant instead of 'und'
See https://api.drupal.org/api/drupal/modules%21field%21field.module/function/field_get_items/7 and https://api.drupal.org/api/drupal/modules!field!field.module/function/field_view_value/7
This has the added benefit of reducing the number of potential security holes you create.
I just finished the "15 min Blog Post tutorial" included in the documentation for cakephp. I was asked for another tutorial to change the layout for first tutorial.
However, I am fairly new to MVC programming/Cakephp and I have no real clue how to do so. Well, I know I need "default.ctp" placed in app/views/layouts/ and I presume I need to include
to include my data? . . .
I am really at a loss of what to do. I set up my default.ctp as I mentioned above, but when I go to localhost:9999/posts the layout is still the same. I guess I need to include a stylesheet (and if so, where?)
I guess if someone can point me in the right direction to a beginner's guide to layout styling or how to use it I would greatly appreciate any help.
I would advice you to read the following from the cookbook: Layouts and CSS. Then copy the layout from /cake/libs/view/layouts/ to /app/views/layouts/ and modify it to your needs. After that create you stylesheet (or modify existing one) in /app/webroot/css/ and include it in your layout.
Create in app/View/Layout a file named "my_posts_layout.ctp"
In your PostController set $this->layout = 'my_posts_layout';
This way you should view the content defined on my_posts_layout.ctp.
Lack of stylesheets has no impact here.
How MVC works in CakePHP:
The router dispatches an incoming request to an appropriate Contoller.
The appropriate Controller function executes (no output, just fetching data, setting up variables).
The appropriate view is rendered. In fact, the output of the view is just contained in $content_for_layout.
What you really get back in the browser is in the layout. Therefore you can put your view's output into the layout by echo $content_for_layout in default.ctp. (Of course you can also have different layouts.) In addition, the layout can be enhanced with elements.
I really recomend the CakePHP CookBook, easily found from the CakePHP homepage. Modifying default.ctp should edit your applications layout.
A more specific question (eg. code samples of your default.ctp, expected results etc) might help people provide a better answer than mine.
What is the best way to create regions in your layout similar to Wordpress's Widgets or Drupal Blocks? What is the best practice method of doing that in CakePHP?
If by regions you mean a special "content container" (never used WP/Drupal), then it's very easy.
There are several ways to accomplish this, but the one that came to my mind first was this:
Create a helper (or an entire plugin) to handle the "which content goes into which container" logic. Shouldn't be too hard to do because you have many Cake utility classes to help you out with that (such as the Configure class). This should obviously be configurable by the end user.
Create containers in your layout, example:
<div class="content-container" id="content-container-left">
<?php echo $yourHelper->outputContent("left"); ?>
</div>
Two options:
Content should be based on elements; or
Content should be based on custom plugins (which actually do their stuff and output the content)
Note: There are probably better ways to accomplish what you want, this is just the first that came to my mind. I'd recommend some pencil-and-paper planning before you actually code anything, it will improve your chances of finding the best way for your app.
I created a Sidebar Helper recently that you might find useful.
You define the content of the boxes in Cake elements, and then add them by calling ...
$sidebar->addBox(array('element'=>'my_sidebox_element');
... this would render the content of views/elements/my_sidebox_element
Alternatively you can specify te content of a box 'inline':
$sidebar->startBox(array('title' => 'My Inline Box'));
<p>blah <b>blah</b> <span>blah</span></p>
$sidebar->endBox();
The in your layout file call
echo $sidebar->getSidebar();
... and each of your boxes will be rendered as divs
Technically speaking this doesn't need to be used as a 'SideBar' - it ultimately depends on how you render the layout with CSS.
See the documented code for more details:
SidebarHelper on GitHub