http://www.meetup.com/Learning-Drupal-Meetup/events/83426292/ was free to anyone sober, organised enough to remember the date, and book a day or so in advance so this time I was able to go! Surprisingly, it's quite easy to sit at the back and be relaxed, and the other 62 attenders looked relaxed too.
John Kennedy of Commerce Guys showed Kickstart 2 which looked good enough to use as it is for shopkeeping, specially now that there are instructions with annotated screenshots. The default site has sized goods in stock and sections to show different types of goods. In the UK they only deal with the biggest customers but "coaching deals" might be affordable and help Commerce Guys get established too.
Asked if there are any rules of thumb about the servers it works on, he says that a security certificate - "SSL Layer" and user authentication add strain beyond the basic Drupal 7. His firm mainly deals with orders over dozens of thousands of pounds, but for people like me the reply meant "use off-site processing to save server costs". Search is a strain on the server too.
Asked if there is an upgrade path from Kickstart 1, he says that there need not be. I'm having trouble though. Today my hard disc server from Aquia Drupal says it would like a new Drupal Core, so maybe that's the hitch. Someone posted suggestions below as well, and I'm sure there's a lecture at a Drupal show somewhere about how to reduce server load. It said that external search helped and that caches help - something called Varnish for anonymous users.
John (?) gave an introductory grammer lesson in Drupal similar to https://drupal.org/documentation/structure which is a bit I have always skipped because I'm keen to get-on with ecommerce. For my own benefit and probably wrong..
Nodes have urls & titles. They can be part of a page, blog, or other content type. They can be displated in part. The default urls are "node" and a number.
Blocks have content & place. They can be (?) pretty much freehand html in a wrapper, or they can be generated by Views.
Themes are an abstracted layer where hypertext mark-up, style sheets and javascript go into one code file called .info . If the theme is called pants, the file is called pants.info .
In are theme, blocks are allocated to Regions along the usual classic lines like header, footer, content, and less classically "sidebar one" and "sidebar two". This new jargon is because users with left-to-write languages like Hebrew use them differently, so they're not labelled "sidebar left" and "sidebar right" any more. This and countless other tweaks and updates like compatibility with mobile browsers are good to get from a base theme, of which there are several, if you want to make your own design on top. Regions for example are fairly easy to create once you have a working base theme.
Taxonomies beg the question: "why the big word for 'categories'?" which is what they are. The answer is that they allow lots of detail. Vocabularies can be part of a Taxonomy. Terms can be part of a Vocabulary. And Terms themselves can have multiple levels. Alongside some of the other bits of Drupal, taxonomies can be looked at on the User Interface (UI) screen linked under the Taxonomies module in the admin section. It looks like a grid at first site. Oh, Tagging by users is also allowed, with the possibility of a "Folksonomy" such as camel and camels being tagged as two different animals by different zoo-keepers. To reduce this, there is a suggestion and auto-complete function in the tag form. Content Construction Kit (now part of Drupal Core) can filter by taxonomy, but without the heirachies and free-tagging. Views can filter by tag. Hierachical Selectors is sometimes a helpful module here. I had never seen the stark version of a taxonomy item displayed before and should have a go - it's a bit like a blog post with links to items further down the hierachy.
Menus: two are created by default called "primary" and "secondary" - rather vague words because they're flexible; from the Menus user interface you can choose whether the secondary menu is a part of the primary menu or separate for example.
Panels and Context are two different ways to achieving what you want on a certain part of a certain page. Panels is more of a package deal that you can use from the panels user interface or some rapidly evolving add-ons: the mini-panels alternative, the Paneliser add-on, and the Panopoly profile which is now part of Open Publish and one of the academic profiles. Context is lighter wieght and niftier.
Talking of Panels, Adrian Webb presented much more than I understand in rather nice husky american accent and leaves this link to his presentation notes about the Panopoly theme.
http://prezi.com/0l_derrjnmbx/introduction-to-panopoly/
John Kennedy of Commerce Guys showed Kickstart 2 which looked good enough to use as it is for shopkeeping, specially now that there are instructions with annotated screenshots. The default site has sized goods in stock and sections to show different types of goods. In the UK they only deal with the biggest customers but "coaching deals" might be affordable and help Commerce Guys get established too.
Asked if there are any rules of thumb about the servers it works on, he says that a security certificate - "SSL Layer" and user authentication add strain beyond the basic Drupal 7. His firm mainly deals with orders over dozens of thousands of pounds, but for people like me the reply meant "use off-site processing to save server costs". Search is a strain on the server too.
Asked if there is an upgrade path from Kickstart 1, he says that there need not be. I'm having trouble though. Today my hard disc server from Aquia Drupal says it would like a new Drupal Core, so maybe that's the hitch. Someone posted suggestions below as well, and I'm sure there's a lecture at a Drupal show somewhere about how to reduce server load. It said that external search helped and that caches help - something called Varnish for anonymous users.
John (?) gave an introductory grammer lesson in Drupal similar to https://drupal.org/documentation/structure which is a bit I have always skipped because I'm keen to get-on with ecommerce. For my own benefit and probably wrong..
Nodes have urls & titles. They can be part of a page, blog, or other content type. They can be displated in part. The default urls are "node" and a number.
Blocks have content & place. They can be (?) pretty much freehand html in a wrapper, or they can be generated by Views.
Themes are an abstracted layer where hypertext mark-up, style sheets and javascript go into one code file called .info . If the theme is called pants, the file is called pants.info .
In are theme, blocks are allocated to Regions along the usual classic lines like header, footer, content, and less classically "sidebar one" and "sidebar two". This new jargon is because users with left-to-write languages like Hebrew use them differently, so they're not labelled "sidebar left" and "sidebar right" any more. This and countless other tweaks and updates like compatibility with mobile browsers are good to get from a base theme, of which there are several, if you want to make your own design on top. Regions for example are fairly easy to create once you have a working base theme.
Taxonomies beg the question: "why the big word for 'categories'?" which is what they are. The answer is that they allow lots of detail. Vocabularies can be part of a Taxonomy. Terms can be part of a Vocabulary. And Terms themselves can have multiple levels. Alongside some of the other bits of Drupal, taxonomies can be looked at on the User Interface (UI) screen linked under the Taxonomies module in the admin section. It looks like a grid at first site. Oh, Tagging by users is also allowed, with the possibility of a "Folksonomy" such as camel and camels being tagged as two different animals by different zoo-keepers. To reduce this, there is a suggestion and auto-complete function in the tag form. Content Construction Kit (now part of Drupal Core) can filter by taxonomy, but without the heirachies and free-tagging. Views can filter by tag. Hierachical Selectors is sometimes a helpful module here. I had never seen the stark version of a taxonomy item displayed before and should have a go - it's a bit like a blog post with links to items further down the hierachy.
Menus: two are created by default called "primary" and "secondary" - rather vague words because they're flexible; from the Menus user interface you can choose whether the secondary menu is a part of the primary menu or separate for example.
Panels and Context are two different ways to achieving what you want on a certain part of a certain page. Panels is more of a package deal that you can use from the panels user interface or some rapidly evolving add-ons: the mini-panels alternative, the Paneliser add-on, and the Panopoly profile which is now part of Open Publish and one of the academic profiles. Context is lighter wieght and niftier.
Talking of Panels, Adrian Webb presented much more than I understand in rather nice husky american accent and leaves this link to his presentation notes about the Panopoly theme.
http://prezi.com/0l_derrjnmbx/introduction-to-panopoly/
No comments:
Post a Comment