xhtml-css coding before Drupal Implementing? - css

I'm going to start my first Drupal project :) pretty excited. I have many questions in my head :/ but I will find out the answers and learn many about Drupal while working on this project.
ok, I have the design completed.
now is it better to make xhtml-css coding of all pages, and then implementing these codes to Drupal?
or is it better to make xhtml-css coding straight into Drupal theme?
Appreciate advices!

I prefer to code the XHTML/CSS first and then copy-paste/adapt it into the templates, everything is more consistent and you can have a real preview of how the page will look like once it is working dynamically (plus test it in different browsers, etc...).
(In my opinion) It is also faster to do it this way because you first focus purely on the Front-end and then start copy-pasting/adapting the code snippets (once you get to develop several themes you can create a code snippet collection with everything you need).
When I have tried to code it straight I always leave unclosed tags, create non-consistent CSS classes/IDs (specially when creating big websites with hundreds of CSS lines) and other minor mistakes in which I need to spend time later fixing...
My best advice is for you to try coding both ways. Then compare which one has been faster to develop, how comfortable have you felt and which one you prefer for your future projects.
Good luck!

I'd say it depends what your goals are. Preparing HTML and CSS before touching Drupal will make you very familiar with Drupal theming and give you exactly the markup you want, but it will come with a big downside of taking a LOT of time.
On the other hand, going with Drupal's default markup as much as possible will be faster and easier, but won't get you as familiar with Drupal theming and will result in some CSS that will probably feel a little bloated compared to your non-Drupal CSS.
Long term, I'd say bending Drupal markup to your will is best, but it may prove more frustrating than satisfying on your first Drupal project.

Related

Can someone explain the purpose of CSS frameworks and why we use them?

So in class, we've been applying css frameworks like Bootstrap, Foundation, Normalize.css but I do not understand what the point is of using them. Can someone briefly explain WHY they are used? How am I supposed to know which framework to use? For example, let's say I made a basic HTML file for my blog and I want to style it. Would I need to use a framework? How would I know which to use? How is it different from just styling on my own from scratch? I know these seem like stupid, ridiculous questions but I just started learning CSS a month ago and do not understand what frameworks like Bootstrap, Foundation, Normalize, etc. are and the purpose of them. Someone please explain as if how they would explain to a little child so I understand? Thanks.
A bit of an opinion-based question, but in short: developers are lazy and it takes time to code sites that are mobile-ready, consistent across browsers, and are easy to manage as browsers get updated.
With frameworks, developers need not waste time figuring any of this out.
For example, with Bootstrap, using the grid system, it is possible to make mobile-ready sites with minimal media queries and complex CSS rules.
Using other people's code, which has been tested on production environments and is constantly being patched and updated, saves a lot of time and a lot of bugs down the road.
You can think of frameworks (in any language, not just CSS) as a bunch of existing reusable codes you can readily use for your own projects. They essentially make your life easier because you don't have to reinvent the wheel anymore. Simply put, frameworks are a bunch of tested reusable codes for common tasks.
The purpose is to avoid having to make your CSS from scratch. There are a LOT of CSS activities that most people do over and over. If you look at a wide variety of sites, you'll notice similarities in the way information is presented. As a result, if you're going to be presenting information using one of those standard layouts, it's vastly easier to simply use a CSS framework than roll your own version.
Also, different browsers have different default CSS settings. Using a CSS framework will provide a CSS reset as part of what they do. This helps ensure that what you see in one browser is what will be seen in all browsers. This helps you spend more time building your site and less time trying to figure out why the display is different in a particular version of IE, for example.
frameworks comes with lots of features like grid, components, typography along with good browser compatibility so you can simple use them instead of creating them from scratch. It totally based on project requirement that what framework you should use. Apart from bootstrap and Foundation there are more great out there created by few geeks.

Magento - How complicated is it to install a custom design?

I am working with a client who has already purchased Magento -eCommerce CMS. I have never worked with this program and after reading over there extremely lengthy material I am not sure if I should take on the project. I am worried that this is a little outside of my skill set. I mostly do Design and Front-End Development. I have worked with Wordpress somewhat regularly without any problems, however that is extremely well documented. My understanding of actual programming is limited. Has anyone created a skin for Magento and if so, how complicated was it?
It depends on how you define complicated. Anyone with a good understand of Magento's architecture MAY actually call it intuitive. I can say that it has a significantly higher learning curve than many other packaged application in frameworks due to its shear number of features. It's extremely easy to think you done and found out from a client that there's a page you failed to style.
To better answer your question I'll tell you what you'll be facing.
CSS:
It is possibile, though difficult, to skin Magento using purely CSS. This can be made easier depending on your design.
HTML:
There are more individual templates than I'm willing to count. I want to say upwards of 40 ".phtml" files that you can edit each with an uncomfortable amount of logic to my taste (and I'm a programmer). For the most part you can manipulate the HTML within these files as you see fit with out any trouble. You probably will have trouble if you need to edit anything logic wise or that output by PHP
XML:
Magento uses xml files for what it calls layouts. These files are actually what puts the template files mentioned above together. To do some significant changes to the default layout you will have to change these.
Realizing that you referenced wordpress. Magento is SIGNIFICANTLY more difficult to skin than wordpress. Even after a very thorough understand of magento's architecture I still get hung up when changes. Magento is full of complex caches which can prevent your changes from being visible and unexpected dependencies which you can easily break if your not careful.
This is probably a horribly written answer but I hope it helps.

A REAL quick, basic CSS layouter

Short story: I frequently have to work on many different, rather small, web pages.
Most of them are layouted with pure CSS.
My Problem:
My job is to work on the code itself, on the functionality of the pages, not on the layout. However, due to the changes I make, I am often forced to make slight layout modifications and that soaks up my time like a black hole.
I end up spending as much as 10 times as long to do the slightest layout modifications as it takes me to add or rewrite routines.
We have a designer as well but it is just impossible to wait for him to redo layouts for every change I make (and often enough I have to change things multiple times).
So what I've searched for is a super basic and simple CSS WYSIWYG editor that isn't a complicated professional design tool. After trying a few tools I gave up, going back to editing by hand. In particular, the behavior of nested layout boxes just freaks me out every time.
Does anyone have some hints on this?
I'd appreciate any help,
Thank you
Two thoughts:
1) Adopt more of an agile process
The visual design (layout) and logic design should be built in tandem rather than one after the other. As you've found out, modifying things after the fact can be a real pain.
2) Adopt a CSS framework/OOCSS methods/Component Library
The idea behind all 3 of those is to create reusable CSS that follows a predictable structure. This takes a lot more up-front work, but results in a code base that should be a lot easier to maintain going forward.
twitter bootstrap
http://twitter.github.com/bootstrap/
looks really good from first impressions.
My rails expert keeps raving about it and I'm planning on trying it. Obviously free 'n all.
Basically we've felt your pain with this issue!
Bootstrap is good for real developers, a lot of it is basic layout via css tags and I think it'll make a lot of sense to you.
Even if it doesn't meet all your needs, it might be a great place to start with, as a standard for a development team. As much as developers often dislike being templated ;)
The actual direct github site is: https://github.com/twbs/bootstrap
Is it used much? Currently?...
Github Stats:
Watcher: 8682
Forks: 1383
Last Update: 10/10/2011
This post: 10/26/2011
Looks good! :)
I'm also a big fan of HAML - Ruby + HTML without the angle brackets(and more)!
... not sure if this will help, but yahoo grid builder works well for me. Of course there is a catch. The css selectors it generates are not very semantic, so you might have to do some re-factoring of them from withing the generated html page.
Github Stats: (for Blueprint suggested by Daniel below)
Watchers: 4556
Forks: 390
Last Update: 06/06/2011
This post: 10/26/2011

Should the designer also have to know Drupal if the developer knows already?

I am working in Drupal. My friend is a designer and he does not know Drupal. If he designs in the usual way and then I convert his traditional HTML into Drupal then will that work? Or does he have to know Drupal also?
One of you will need to learn at least the basics of Drupal theming; however, most any design can be adapted to be a Drupal theme. I've adapted plenty of basic HTML themes, WordPress themes, Joomla themes, and others into Drupal themes.
The more experimental or cutting edge the design, the more effort it will take to make it work with Drupal. For instance, Mega Menus are not easy to implement in Drupal because of the way Drupal's menu system works.
Apart from avoiding stuff like Flash, the designer doesn't need to know a lot about Drupal. I've taken numerous designs from non-Drupal designers, and they tend to fall into two categories.
HTML designs. These tend to be the easiest by just turning a bog standard HTML file into a tpl file and replacing the content with print statements for Drupal regions and other bits. There can be some work needed for thing actual content, but the basics can usually be done in a couple of hours.
Photoshop designs. In this case the designer knows little about web design, but knows how to draw pretty pictures. As long as the designer puts everything on separate layers, these can work well. I start with the Zen theme, slice up the Photoshop file, and insert the graphics and add colours to the CSS. Generally more work than 1, but I can usually produce a basic theme in about a day.
Of course, the less the designer knows about Drupal, the more expert the developer needs to be.
Totally not. I (as the Drupal developer) have worked with someone who had CSS/HTML chops like few others ( not just wrote books on it but actually knew what he is doing :) ) he gave me HTML and I made Drupal emit that HTML.
Drupal is very flexible. If the person implementing the theme is relatively acquainted with the Drupal theming system, the designer should not need to know a great deal about Drupal. The vast majority of designs can be implemented effectively with the Drupal theming system.
It is best if he works with a starter theme such as Zen http://drupal.org/project/zen
Zen is very easy to build with for designers, and they do not need to know much about Drupal to work with it. When they are finished, they will have a theme that works with any Drupal install.
In answer to your question then, the answer is no.
I think you should give him a short run-down so he understands how Drupal works, so he can assure his designs don't 'fight' with the undelying framework. But I don't think he needs to know how it's done step by step (it wouldn't hurt though, is my guess).

Why is drupal theming so difficult? Any tips for simplifying it or learning it faster?

I've been coding in PHP for 4 years and even I find it so convoluted and hard to grasp. I have no idea how they expect designers to manage theming.
I know basic theming, theming with tpl files, views templates, contemplate templates etc. However I get lost whenever I enter the template.php file.
I needed to theme a node input form for a custom content type. I wracked my brain over it with like 7-9 tutorials and it's still not coming together. I understand why module building can be complicated - because most people who work with modules are developers anyway.
However, when even a developer can't understand theming, it's definitely over-engineered!
Maybe it's my fault, maybe I didn't learn Drupal properly. In that case, is there a step-by-step system to becoming a Drupal guru?
Theme is really not that difficult, if you only know basic php. You have 3 ways of altering the markup, the css and js, you should be able to handle.
Template files. By creating a template file in your theming and naming it correctly, it will take precedence over other template files, and you can thus create custom markup for views, nodes etc. By creating a template for a noce type, you can do stuff like printing out the cck fields in any other instead of using $content. All you need is on the node object.
Preprocess functions, which are placed in your theme, will give you the possibility to add or alter variables that will be used in your template. You name the functions like hooks: yourtheme_page for the page template yourtheme_node for the node template etc. Here you can create some custom logic, or modifications, to help make your templates more clean and just handle the printing of the variables.
Theme functions. You can overwrite theme functions to alter the markup that's used. You only need to create a function called yourtheme_[theme_function_name]. You don't need to understand much php to do this. Often, you can just copy the original theme function, and make a few alterations in it to get the markup you want.
With the above you can do 90-95% of what you need. Forms are a bit special since you in Drupal 6 can't alter them (easily) in your theme. Instead what you want is to create a small module and use hook_form_alter, which allows you to modify the form, text used on buttons etc. This is changed in Drupal 7, which will be even easier to theme.
So it really isn't all that complicated, just use the 3 basic tools described above. The tricky part can be to name your functions and templates, but devel themer can help you with that. Another tool you use is devel which can assist you in printing out variables so you can inspect them and see what you have available, fx CCK fields on the node.
Maybe you should get a copy of Front End Drupal.
In my opinion, Drupal theming is not difficult once you wrap your head around the concepts like templates, overrides, .info files and preprocess functions. Those things are not directly related to php skills, it's all about understanding the system.
It's interesting to see that you're a themer, yet you only talk about php, not CSS and HTML. In my experience, a lot of theming tasks can be accomplished with CSS, without even touching php.
Finally, I don't know if you are using a base/starter theme (like Zen or Genesis) already. I recommend using a base theme and realizing your own design as a sub theme.
Most people get an 'ahah!' moment when themeing suddenly starts to make sense.
I'd argue that this is probably tougher for experienced PHP developers, since you have to get past a lot of concepts that don't make sense in vanilla PHP ("the function is magically called at the appropriate time ... because of how it's named?!")
#googletorp's answers is pretty comprehensive, so I'll just add some practical tips that helped me along:
1) Try building a module that implements it's own themeable output and simple hooks. Hooks and theme functions make a lot more sense when you see how modules are actually calling them and using them.
2) Make liberal use of the devel module, especially the Theme Registry menu (note how it changes when you add a new theme function), the 'Render' tab, and the dpm() and dvm() functions
3) Buy a old-tyme dead-tree book on Drupal themeing. The online docs are really outstanding if you already know what you're doing, but can be extremely confusing if you're not sure what you're looking for.
4) Empty your cup. At the theme level, PHP is really just for simple logic and syntax -- almost everything of substance is getting handled by Drupal API functions. Try to think like a Drupal developer and not a PHP developer (i.e. don't assume you know how to do something just because you built a vanilla PHP site that does the same thing) and you'll have an easier time.
Keep with it! The theme system is actually really easy to use once you've figured it out.
to answer your question on why it is so hard:
Drupal themes may seem overwhelming, due to the sheer amount of possibilities, see #googletorps answer for a good overview.
Having "many ways to do one thing" brings power: power users can choose the best of all possibilities. But it also brings complexity: new users don't get a good lead, because there is no "you should do it this way. fullstop."
Alongside that amount of ways to get stuff done, there is the problem of nesting. Drupal has a concept of very deeply nested items. To take a random, yet simple example:
username<menuitem<menuitem<menuitem<menu<block<region<page.
Will render a menu-item, containing a username in a three level deep menu-item in a sidebar-block.
Where most templating-environments have concepts of a page, containing several "contents" that, at most, might contain some partials. the nesting is at most three levels deep. And each level has a clear, distinct area of expertise. Drupal does not have that: the nesting is fairly arbitrary. And each nested item is no different from its parents. This, again, offers power-users a great concept and power to work with, but is hard to grok for new developers/designers.
Lastly, another reason why it is hard to learn, is that the Drupal online documentation is more a wiki then a read-from-begin-to-end manual. There are great books that fill htat gap, you will have to buy them, though.
If you haven't seen it already, this is a great presentation on why Drupal 6 theming is difficult and how it is improved in Drupal 7. There is hope! The video made more sense to me a second time watching after more experience theming.
http://sf2010.drupal.org/conference/sessions/design-and-theming-whats-new-drupal-7
One of the biggest tricks is to override something that is normal rendered with a theme function into a template. This gives you much more control over the markup, and also lets you use the preprocess functions to manipulate the variables before handing it over to the template.
This is a huge boon to theming forms. See a short video that explains it better than I could here: http://drupaldojo.com/session/fine-tuning-ui-theming-forms-drupal-60

Resources