First, let’s assume a few things:
1) the package is named ‘Company’ and the module is named ‘Module’
2) you know how to make a php module and a new block class. The block’s alias is in this example ‘module/dynamic’
3) the phtml template for the dynamic block will be dynamic.phtml
4) the block id of the static cms block will be ‘static_block’ (and you already created it in the admin)
5) you need to add the email of the current customer to the static block. The logic of when you want to show the block and everything deeper is out of the scope of this document.

First let’s look @ the phtml file, which only uses the method which we’ll create afterwards in the block class:

<?php if(Mage::getSingleton('customer/session')->getCustomer()->getId()) : ?>
	<?php echo $this->getStaticBlock();?>
<?php endif;?>

As you see, we’re only checking if the customer is set and are getting the static block. So next let’s see the logic in the dynamic block class:

<?php
/**
 * Just another block class
 */
class Company_Module_Block_Dynamic extends Mage_Core_Block_Template
{
	/**
	 * This getter will return the html of your static block
	 * @return string
	 */
	public function getStaticBlock()
	{
		// loading the static block
		$block = Mage::getModel('cms/block')
		->setStoreId(Mage::app()->getStore()->getId())
		->load('static_block');
		/* @var $block Mage_Cms_Model_Block */

		// setting the assoc. array we send to the filter.
		$array = array();
		// the array keys are named after the tags in the static block. let's say $array['customer_email'] is {{var customer_email}} in the static block. you can set as many variables you need.
		$array['customer_email'] = Mage::getSingleton('customer/session')->getCustomer()->getEmail();

		// loading the filter which will get the array we created and parse the block content
		$filter = Mage::getModel('cms/template_filter');
		/* @var $filter Mage_Cms_Model_Template_Filter */
		$filter->setVariables($array);

		// return the filtered block content.
		return $filter->filter($block->getContent());

	}
}
?>

Ok. Now enter somewhere in your static_block CMS block the tag {{var customer_email}} (or some other key you added) and it’ll be dynamically added into CMS block.

Since the part1 article 4 new codes were introduced in newer Magento versions, so now there’s 10 of them total: skin, media, htmlescape, store, block, layout, config, customvar, protocol and widget.

They are currently handled by Mage_Widget_Model_Template_Filter processor class (which extends Mage_Cms_Model_Template_Filter which extends Mage_Core_Model_Email_Template_Filter).

5. blockDirective

Description: Prints out cms static block or any block defined by type

Example:
{{block id=”static_block_code”}} – static block example
{{block type=”core/template” template=”custom/test.phtml”}} – core/template block with defined template

Synonym:
Mage::app()->getLayout()->createBlock(‘cms/block’)->setBlockId(‘static_block_code’)->toHtml();
Mage::app()->getLayout()->createBlock(‘core/template’)->setTemplate(‘custom/test.phtml’)->toHtml();

Params:
id = static block code; if id is set type is always cms/block
type = block type, same as in layout files
Any additional parameter provided will be passed on to block object (template=”custom/test.phtml” from above example will trigger ->setTemplate(“custom/test.phtml”) on that block)

6. layoutDirective

Description: Reads and prints out layout handle defined in your layout xml files

Example: {{layout area=”frontend” handle=”my_layout_handle”}}
<sales_email_order_items> layout handle defined in sales.xml is used this way in order e-mail templates for example.

Synonym:
$layout = Mage::getModel(‘core/layout’);
$layout->getUpdate()->load(‘my_layout_handle’);
$layout->generateXml()->generateBlocks();
echo $layout->getOutput();

Params:
area = frontend or adminhtml
handle = layout handle
Any additional parameter provided will be passed to every block defined in layout

7. configDirective

Description: Prints out Magneto config value. Use predefined through Insert Variable dialog in editor.

Example: {{config path=”general/store_information/address”}}

Synonym: Mage::getStoreConfig(‘general/store_information/address’);

Params:
path = config path

8. customvarDirective

Description: Prints out Custom Variable HTML Value (System->Custom Variables in admin). Can be easily added through Insert Variable dialog in editor.

Example: {{customvar code=”my_custom_var”}}

Synonym: Mage::getModel(‘core/variable’)->loadByCode(‘my_custom_var’)->getValue();

Params:
code = custom variable code

9. protocolDirective

Description: Prints out current protocol (http or https) for absolute links

Example:
{{protocol}} – current protocol http or https
{{protocol url=”inchoo.net/”}} – domain URL with current protocol
{{protocol http=”http://inchoo.net” https=”https://inchoo.net”}} – one or another

Params:
url = url to print with proper protocol prefix http(s)://; (for Magento links use {{store}} code)
http + https = prints out https value if viewing secure page, http value otherwise
store = optional store id to check secure by that store; I’m not exactly sure what’s the purpose of this

10. widgetDirective

Description: Prints out defined widget. Magento widgets automatically insert these codes, for manual custom usage it’s probably better to use block codes.

Example: {{widget type=”catalog/product_widget_new” products_count=”5″ template=”catalog/product/widget/new/content/new_list.phtml”}}

Synonym: Mage::app()->getLayout()->createBlock(‘catalog/product_widget_new’, null, array(‘products_count’=>5, ‘template’=>’catalog/product/widget/new/content/new_list.phtml’))->toHtml();

Params:
type = widget type, similar as block type
name = determine what name block should have in layout; probably needed only if more than one same widget is used on same page
Any additional parameter provided will be passed on to widget object. There is also code that accepts id param, but it currently does nothing useful.

Please be careful when copy/pasting examples from this article directly into Magneto, readers have reported that quotes get messed up in the process sometimes. Please type in manually.

To be continued .. Ivan

If you want to use forms in Symfony 2 project there is already prepared system for that.

First in ‘Yourname/SomethingBundle/Forms’ folder create class like this:

<?php

namespace Surgeworks\AdminBundle\Forms;

use Symfony\Component\Form\Form;
use Symfony\Component\Form\TextField;
use Symfony\Component\Form\HiddenField;

//form for Create and update information about languages
class LanguageForm extends Form{

    protected function configure() {
        $this->add(new TextField('language_name',  array('max_length'=>50, 'required' => true)));
        $this->add(new TextField('language_symbol',  array('max_length'=>10, 'required' => true)));
        $this->addOption('name', 'adminForm');
    }
}

then the form is ready for using inside controller:

    /**
     * @extra:Route("/admin/languages/add_new", name="_admin_languages_add")
     * @extra:Template
     */
    public function addAction() {

        $form = LanguageForm::create($this->get('form.context'), 'adminForm');

After that in the same controller action bind form to your existing Entity:

$request = $this->get('Request');
            $form->bind($request, $language);

Attention: make sure that form field names is same like your Entity properties names!

One little tip: When field names in Entity class contain _ (underscore) character, make sure to remove that character in setter and getter function names, for example:

//contains underscore character like fieldname in database
protected $status_id;
//theese methods must be without that character
    public function getStatusId() {
        return $this->status_id;
    }
    public function setStatusId($status_id) {
        $this->status_id = $status_id;
    }

For displaying form in the template there are several ways, end one of them is:

        <form action="#" method="post" id="adminForm" enctype="application/x-www-form-urlencoded">
    {{ form_errors(form) }}
    {% for field in form %}
        {% if not field.ishidden %}
            <div class="formitem">
            {{ form_errors(field) }}
            {{ form_label(field) }}
            {{ form_field(field) }}
            </div>
        {% endif %}
    {% endfor %}
{{ form_hidden(form) }}
                <input type="submit" value="submit"/>
        </form>

In the next article of Symfony 2 series I will write about validating form’s data in Symfony 2.

It’s not so heavy, but you have to pay attention on some really important things and because of that, I would like to say that it is not heavy but more sensitive task to do.

So, let’s start with article.

Imagine this situation:
We have one live site on http://somedomainold.com with fully functional WordPress installation, many articles, plugins installed on the site. Let’s say that current database is bigger than 500 Mb. We have access to control panel, ftp and also ssh on live server.
Now we want now to copy same WordPress installation to http://portal.somedomain.com (into sub-domain of new domain on new server).

Why did I mentioned SSH?

Because I don’t want to download database file and then upload it again on new test server but I want to transfer whole data without downloading it.
(Of course, in this case we must have ftp and ssh access to new server also).

TIP: For those that never used SSH before, I would advice that use Google for basic UNIX terminal commands, because they would need them.

First of all, we have to back up live site (just in case something goes wrong) and also we can use backup to transfer both database backup and files backup to new server without problems.
Often it could be done through control panel of live site. If not, there are alternatives, but I will talk just about first mentioned case for now.

When backup of whole site is finished, copy that ‘somefile.tgz’ backup file into public folder either from control panel or from some root ftp access so we could download that file via URL (for example: www.somedomainold.com/somefile.tgz. (Do not forget to delete it after transferring!)
Next, we have to connect by SSH to new server with our credentials (I often use Putty for SSH access because it is relatively simple, but there are more tools available for free).
Fire up Putty and enter basic connection information in sessions category: Host-name / IP address of server we will connect to and press ‘Open’ button to start the session.

If all went right you should see console like this:

Now it’s time to do some UNIX stuff.
First we want to choose our folder on server where we will host out new wordpress installation. (Using comands “cd”, “ls” will give us that possibility).
Next, we need to is ‘download’ that backup file from old server to new. We can do it with “wget” command in terminal.

After that we want to decompress our downloaded backup package and move site files from inside unpacked folder to our sub-domain directory and also extract our sqldump file so we could restore it on our mysql database on new server. (I didn’t mention that we should first create mysql database and assign a database user with root credentials to it and one of the easiest possibilities is to do that through control panel of new site).
For file decompressing you can use ‘tar -zxvf yourfile.tar.gz ‘.

Because I went too deep in details, let’s back to main theme.

After these ‘few’ steps, we should ensure that all is on it’s place, so finally we should finish with folder structure like this:

/html/portal/
here should be out wordpress installation (index.php, .htaccess, folders wp-content etc.)

(By the way, folder ‘html’ is in our case root domain public directory and folder name portal is our sub-domain folder where http://portal.somedomain.com points to). Why is this important? Because of .htaccess setup later in this article.

Next we should replace all occurrences of ‘http://somedomainold.com’ with ‘http://portal.somedomain.com’ in our sqldump file.
First time I tried to do that with ‘nano’ text editor in SSH terminal, but database was too big for that editor, so Putty and SSH connection crashed every time and I decided to take advantage of another tool in terminal, so I used ‘vi’ editor for that purpose because it won’t load whole file in memory, just visible part so terminal wouldn’t crash.
(Use Google to search for ‘find and replace with vi’ tutorial).

After replacing domain names in sql dump file save it and exit vi editor.

So, now we have files of site on right place and also sql dump file ready to restore to new database.
(of course while ‘vi’ editor is open we should probably add line on top of existing sql statements: USE new_database_name; )

Let’s Google again for instructions how to restore sql dump file to mysql using console. There are plenty of tutorials doing that.

When restoring database is completed we are almost ready to start our transferred wordpress site.

Open up your browser and try to enter to wp-admin: http://portal.somedomain.com/wp-admin,
log in with old site credentials and check general settings for updating URLs of the site. Also check permalinks settings and save it again.
If new wordpress site is not working or displays only frontpage and not other pages in menu, probably is some problem with rewrite and / or permissions in .htaccess file. So in that case – delete .htaccess file or rename it via ftp and go to wp-admin – > settings – > permalinks again and save it again and new .htaccess file will be created with some wordpress lines.
From my experience because our installation was in root domain before and now is on subdomain,
we need to add subdomain folder name before /index.php in .htaccess file (like on image) and all should be OK.

Maybe there are easier ways to move site, maybe there are better ways, but I felt that I have to write about that from my experience before, so thank you for reading .

Internal linking – After years of expectations WordPress will gain more on CMS functionality then ever and make wordpress even more SEO efficient.

Writers will now have the ability to browse thru posts and pages from the admin and add the internal links directly while writing the post. Guess I’ll stop using dedicated desktop apps that don’t support that.

Front-End Admin Bar – Having the back-end on the front-end in terms of a on-top placed administration bar will provide easy access to the dashboard, post writing etc.

This would come in handy for multisite wordpress sites and for those who like having some bar sitting on top Judging by the community feedback it’s a very welcomed feature.

Admin Screens on AJAX – This one will allow reordering/sorting columns for the admin interface. One great application of this is with the sorting, pagination and most importantly searching. Hope this one gets applied to comments also but as they state on their dev blog “it’s still being reviewed for inclusion”.

Next presented features are more interesting to developers and advanced users since they bring WordPress even closer to that CMS flavor:

Advanced taxonomy queries – The taxonomy queries, as announced, should be easier to create and enable sorting posts and pages a lot easier. I guess that recreating multiple taxonomies through categories should be a thing of the past.

Something like: “I’d like a list of all your cars without the stereo please”. “Yes sir, here you are.” but without wordpress actually talking with the user

Post templates / Post styles – This feature brings WordPress a few steps closer to an actual CMS with the ability for the user to select a pre-defined post template or post style, carefully prepared by a developer and accessible via drop-down.

All of these improvements are also accompanied with bug fixes and of course, some UI changes and enhancements. This will also be the last version to support PHP 4.

The release is scheduled for December 15, a month after the Beta release.

You can read their full process and scope at their dev blog.

Why would I wanna do this? As I said, I like the flexibility and the power built in, so why not make my self a WordPress like CMS based on Magento core.

Took me two days to get satisfying results as you can see on the image. I ended up having only 9 modules under app/code/core/Mage folder.

I kept the Customers module since it integrates full registration and authentication of users. After deleting sufficient files (controllers, blocks, modules), size of system drastically reduced (which is to be expected). During this process I noticed several places where some module (singleton) calls are coded into core module, although they should not be. After few deleted lines of code and minor logic change to patch those “coded” values, system is working without any noticeable issues (for now ).

Next stop, traverse trough all of the 9 remaining modules and fix the rest of dependency code that might point to removed modules. And final step, fully remove Prototype from system and throw in jQuery. Should be trivial on frontend since I am left only with CMS static pages and AccountController.

I have decided I will not distribute this “modified” version of Magento, due to possible implications on subject of legality. Hopefully, no hard feelings on readers side . This is merely my private little project from which I will continue building my own CMS for my own private use.

Cheers.

As strange as this may sound, processor class that gets called is Mage_Core_Model_Email_Template_Filter located at app/code/core/Mage/Core/Model/Email/Template/Filter.php .

There are also some interesting directives in superclass Varien_Filter_Template, but if i’m not mistaken, none of them can be used.

There are six replacement codes  that can be used and each triggers its equivalent Directive function:

skinDirective
mediaDirective
htmlescapeDirective
storeDirective
blockDirective
layoutDirective

I’ll start with easier and most commonly used and continue with advanced ones in part two of this article.

1. skinDirective

Description: Used to retrieve path of skin folder and its files, theme fallback respected
Example: {{skin url=’images/image.jpg’ _theme=’blank’}}
Synonym: Mage::getDesign()->getSkinUrl($params['url'], $params)
Params:
url = empty or relative file path
_theme = alternative theme, fallbacks if file not exist
_package = alternative package
_area = alternative area(frontend,adminhtml)
_type, _default etc. = nothing useful, somebody please correct me if i’m wrong

2. mediaDirective

Description: Used to retrieve path of root/media folder and its files
Example: {{media url=’image.jpg’}}
Synonym: Mage::getBaseUrl(‘media’) . $params['url']
Params:
url = empty or relative file path

3. htmlescapeDirective

Description: Used to escape special html chars
Example: {{htmlescape var=’<a href=”www.inchoo.net”>inchoo</a><b>inchoo</b><i>inchoo</i>’ allowed_tags=’b'}}
Synonym: Mage::helper(‘core’)->htmlEscape($params['var'], $params['allowed_tags'])
Params:
var = string to escape
allowed_tags = comma-separated list of allowed tags

4. storeDirective

Description: Used to build magento routes and custom urls
Example: {{store url=’customer/account’ _query_a=’8′}}
Synonym: Mage::getUrl($params['url'], $params);
Params:
url = magento routers url
direct_url = normal url, appended to baseurl
_query_PARAMNAME = adds query param, for example _query_a=’8′ adds a=8 to url
_fragment = adds fragment, for example #comments
_escape = escapes “,’,<,>
custom = if using magento route url param, every custom param added will be appended like /a/8/b/10

I probably missed something in this last one, but it’s very late and i’m tired of poking through Magento

To be continued ..

EDIT: Magento CMS syntax – part2

1. Download FLIR from FLIR homepage. I was using latest 1.2 stable for this article because of simplicity, but if you try you’ll find out that 2.0 beta also works great but requires little more configuration.

2. Unpack FLIR content (cache,fonts,etc.) inside skin/frontend/default/default/facelift
I think it makes perfect sense to put it into skin folder.

3. Open app/design/frontend/yourpackage/yourtheme/template/page/html/head.phtml and append

<script language=”javascript” src=”<?php echo $this->getSkinUrl(‘facelift/flir.js’) ?>”></script>

<script type=”text/javascript”>
document.observe(“dom:loaded”, function() {
FLIR.init({ path: ‘<?php echo $this->getSkinUrl(‘facelift/’) ?>’ }, new FLIRStyle({ mode: ‘wrap’ }) );
FLIR.auto();
});
</script>

If your php error reporting isn’t disabled add error_reporting(0); somewhere on top of config-flir.php. This is main config file from which you can define options and custom fonts, so examine it.

Refresh your Magento store and you should see the result.

flir.js can also be alternatively included from layout files inside head block
<reference name=”head”>
<action method=”addItem”><type>skin_js</type><name>facelift/flir.js</name></action>
</reference>

There is nice Quick Start Guide and Documentation available from FLIR homepage, so i won’t go in details on some advanced FLIR settings, but here are few examples:

//pass selectors as comma separated list
FLIR.auto(‘h5,h4′);
//pass an array of selectors
FLIR.auto( [ 'h4', 'h5' ] );
//replace manually with custom options
FLIR.replace( ‘div.box h4′ , new FLIRStyle({ mode: ‘wrap’ , css: {‘font-family’:'arial’} }) );
//prototype way
$$(‘div.box h4′).each( function(el) { FLIR.replace(el);  } );

Cya.

As title says I’ll show you how to implement simple random banner rotation functionality in Magento using static blocks.

First of all, upload images you want to use in “/skin/frontend/YOUR_INTERFACE/YOUR_THEME/images/”

In admin panel add N static blocks (“CMS->Static Blocks->Add new block”)

For identifier field use something like this:

SomeBannerIdentifierName_1
SomeBannerIdentifierName_2
SomeBannerIdentifierName_3
...
SomeBannerIdentifierName_N

For each content use this:

<a href="ADDRESS_YOU_WANT_TO_USE"><img src="{{skin url=images/media/IMAGE_YOU_WANT_TO_USE.jpg}}" alt="Some alt text"  /></a>

Please note that you are not restricted only to images, you could use text, video or whatever you want here, but I’ll focus on images with links as title says.

Now when all is set, make new file called banner_rotator.phtml in  “/app/design/frontend/YOUR_INTERFACE/YOUR_THEME/template/callouts/banner_rotator.phtml”

And use this code inside:

< ?php
echo $this->getLayout()->createBlock('cms/block')->setBlockId('SomeBannerIdentifierName_'.mt_rand(1, N))->toHtml() ?>

*Make sure you replace “N” with highest number of your static block

In order to show this block, you should be familiar with Magento layouts.
Since that is out of scope for this article, I’ll show you how to put it below the content on cms pages.

Open “/app/design/frontend/YOUR_INTERFACE/YOUR_THEME/layout/cms.xml”

[*] Put this line:

<block type="core/template" name="home.banner.rotator" template="callouts/banner_rotator.phtml"/>

Find this:

<cms_page>
<reference name="content">
<block type="cms/page" name="cms_page"/>

P U T  [*] H E R E  ! ! !

</reference>
</cms_page>

Unfortunately I can’t be more specific so feel free to ask me anything.

UPDATE:

If you want this to work for specific page such as homepage do this:

Instead of here /app/design/frontend/YOUR_INTERFACE/YOUR_THEME/layout/cms.xml
put this:

<reference code="content">
<block type="core/template" name="home.banner.rotator" template="callouts/banner_rotator.phtml"/>
</reference>

into your Admin panel’s CMS->Pages->Your page->Design->Layout Update XML field
Everything else is the same…

Then activate it: app/etc/modules/Inchoo_AdditionalCmsPageLayouts.xml

<?xml version="1.0"?>
<config>
<modules>
<Inchoo_AdditionalCmsPageLayouts>
<codePool>local</codePool>
<active>true</active>
</Inchoo_AdditionalCmsPageLayouts>
</modules>
</config>


Add your page/custom-static-page-1.phtml template file (or copy some default one for start) and you’re done There is also tutorial about this on Magento Wiki. However i don’t like approach of duplicating and overriding Mage files from /local, if it can be avoided, so i decided to write this small and useful example of adding or overriding default Magento settings through separated config files. And yes, Magento values can be overridden this way. Default layouts config can be found in app/code/core/Mage/Cms/etc/config.xml along with used xml code structure, so check it out. Thank you for listening!

Internet is full of “your language sucks, mine is better”, “your language framework sucks, mine is better”. To be honest, I’m sick of it. The way I see it; C#, python, php, ruby, java… are all great and powerful languages. Using one over other will not make you write great application just like that. There is only one thing I consider advantage in web development, and that is using interpreted language over compiled one. This however is merely my preference.

Here’s a link to some pretty useful material on application architecture, Application Architecture Guide 2.0. Architecture Guide 2.0 is about designing applications on the .NET Platform.

Here is another one for web apps, Web Architecture Pocket Guide.

I’m a PHP developer, however I like to throw a few lines of code in C# from time to time. Although books are related to Microsoft .Net platform, if you are not short sighted (in terms of technology), I’m sure you will find these books useful reading whatever platform you might be using.

<a href=”http://video.msn.com/?playlist=videoByUuids:uuids:e615c682-0b89-4c90-8b31-d7b5dbf40283&#038;showPlaylist=true” mce_href=”http://video.msn.com/?playlist=videoByUuids:uuids:e615c682-0b89-4c90-8b31-d7b5dbf40283&amp;showPlaylist=true” target=”_new” title=”Train the Trainer – Application Architecture Guide 2.0″>Video: Train the Trainer – Application Architecture Guide 2.0</a>

There were some really interesting replies.

Advantages:

• It’s free
• Fast to setup
• Easy to learn
• Lots of plugins and templates available so you don’t need to be a PHP guru or designer to have a nice looking site with lots of features.
• Easy to modify page templates allowing you to customize the presentation layers to your heart content
• Large and active open source community community of people developing add-ons, plugins, themes frequently
• Easy to host with simple requirements

Disadvantages:

• Many of the themes have a tendency to look the same or similar.
• PHP’s track record for security is pretty bad.
• Database queries may be very heavy
• It isn’t a full CMS product – which is fine for a lot of sites – but if your site is moving a long way away from something based around a blog then you might find it starts to creak a bit!

http://www.linkedin.com/answers/technology/web-development/TCH_WDD/308438-15378406

Many of the people think that WordPress is still just for blogging and if you want some decent CMS, you should consider Drupal. This quote summarizes those thoughts:

Most of the disadvantages come in when someone tries to warp it outside of being a blog, when they stack on a ton of plugins that try to make WordPress take the place of Joomla or Drupal. It doesn’t. When people try to make it do that, it does it to a lower performance level, and has more sustainability problems.

What are your thoughts about this topic. Feel free to post the comment here or if you are a LinkedIn user, you can reply there.