Categories
Blog Magento

Magento 2 installing new php library via composer

Hi,
I had to install php library phpoffice/phpexcel for reading and writing excel files with php. The easiest solution seemed to be to use composer. But running the command
composer require phpoffice/phpexcel
gave me an error:

composer require phpoffice/phpexcel

[Composer\Downloader\TransportException]
Invalid credentials for 'https://repo.magento.com/packages.json', aborting.

require [--dev] [--prefer-source] [--prefer-dist] [--no-plugins] [--no-progress] [--no-update] [--update-no-dev] [--update-with-dependencies] [-ignore-platform-reqs] [--sort-packages] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--] []...

There were a couple of things I had to do to make my composer install the needed library.

Add your public and private keys

In order to use the composer with magento 2 you first need to add the authentication details to your magento. That’s easy-peasy.

  • Go to magento marketplace and sing in to your account or if you have none, then sign up and create the account.
  • Click on Access Keys in your profile. And this will take you to the area with your access keys.
  • Here you’ll see a big orange button “Create new Access Key” – click on it and it will open a modal with input form. In the input field write down you project name (like “text.com”) and click on ok. This will generate both public and private keys.
  • You will now see your access keys in table below.

Now let’s add our access keys to our magento installation.

  • Go to admin area of your store
  • There go to System -> Tools -> Web Setup Wizard
  • Then click on System Configuration and it will open the form with private and public key input.
  • Fill in the needed data by copying the access keys from magento marketplace and click save config

And voila! You should be done now and should be able to run your composer command.

Not working even though i added the keys

If you’re like me, then there will be some difficulties. If you added the access keys and it still gives you the same error then check your composer by running:
composer diagnose

In my case running this gave me this notice:

composer diagnose
Checking composer.json: FAIL
The version field is present, it is recommended to leave it out if the package is published on Packagist.
Defining autoload.psr-0 with an empty namespace prefix is a bad idea for performance
require.composer/composer : unbound version constraints (@alpha) should be avoided
Checking platform settings: OK
Checking git settings: OK
Checking http connectivity to packagist: OK
Checking https connectivity to packagist: OK
Checking github.com rate limit: OK
Checking disk free space: OK
Checking pubkeys:
Tags Public Key Fingerprint: xxxxxxxx xxxxxxxx xxxxxxx xxxxxxx
Dev Public Key Fingerprint: xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxx
OK
Checking composer version: FAIL
You are not running the latest stable version, run `composer self-update` to update (1.0.3 => 1.4.2)

It turned up that my composer version was old. So i simply run the next command:
composer self-update

And updated my composer to new stable version.
After it completed the update I again ran my line:

composer require phpoffice/phpexcel

And guess what – i worked! I finally installed the needed library.
I really hope this little post helps some one whose composer is not playing along.

Cheers!

Categories
Blog Magento

Magento 1 redirect to home page after login

Hi,
I had to do a simple redirect to home page after customer is logged in, instead of him going to customer account page. The way you do it is using an observer. Magento 1 has an event that fires after login is completed, and this is the event that we’d need. First change the customer settings in system configuration, set Redirect Customer to Account Dashboard after Logging in to No (it’s in the System->Configuration->Customer->Customer Configuration section).

Then make a small extension or if you already have made one add this part in the config.xml:


...
<frontend>
    <events>
        <observers>
            <controller_action_postdispatch_customer_account_loginPost>
                 <my_login_redirect>
                        <type>singleton</type>
                        <class>my_extension/observer</class>
                        <method>homeRedirect</method>
                 </my_login_redirect>
            </controller_action_postdispatch_customer_account_loginPost>
        </observers>
    </events>
</frontend>
...

This is the first part. We need to catch the event that signifies that login is finished, so we catch Magento’s controller postdispatch event on loginPostAction. Now we do the observer part that actually redirects our customer:

<?php
class My_Extension_Model_Observer{
    
    public function homeRedirect(Varien_Event_Observer $observer){
            Mage::app()->getResponse()->setRedirect(Mage::getUrl());
    }
}

And voila! Your customer will now be redirected to the home after he logs in. I will put the small extension for download later on.

Cheers 🙂

Categories
Blog Magento

Magento “Wrong tab configuration ….”

I made myself this problem today, and lost a half an hour trying to figure out what was wrong. So I decided to write a blog post about it, just so I don’t forget.

I had to add new tab to order view in admin area of Magento. I did everything by the book, but for some reason, when I refreshed the order view I got an error report screen. And the report said:

a:5:{i:0;s:24:”Wrong tab configuration.”;i:1;s:2023:”#0 [internal function]: Mage_Adminhtml_Block_Widget_Tabs->addTab(‘user_upload_ima…’, ‘mymodule/sale…’)

Whaaaat?!?!?! But, but, but…. I’ve set up everything correctly! Then next half an hour I was changing this and that before I decided to open Mage_Adminhtml_Block_Widget_Tabs and put echo “here” in various places in function addTab. At the end I saw that when I dumped the $tab variable it was:

boolean(false)

So I remembered. I didn’t have any blocks defined in this module prior to this one – have I even set up block class in my config.xml? I checked the config.xml and of course there was no block class setup.

So to solve the error. all I had to do is add this to my config.xml file:

<global>
    ....
    <blocks>
            <mymodule>
                <class>My_Module_Block</class>
            </mymodule>
     </blocks>
     .....
</global>

Cheers 🙂

Categories
Blog Magento

Magento 1.9.1.0 and 500 Internal server error

HI,
we recently begun working on a web shop whose owner wanted color swatch option for her store. We felt very lucky that Magento CE 1.9.1 came with that functionality. So we upgraded store from 1.9.0.1 to 1.9.1.0 But as usual, Magento upgrade didn’t go without problems. After the upgrading was finish, we coldn’t open the store. All we saw was a blank screen with 500 Internal server error displayed.

We tried making a downgrade back to 1.9.0.1. and then again upgrade to 1.9.1.0 As soon as we downgraded the store it was working normally. But the minute we upgraded it, it again displayed error 500. This only ment that there was something wrong with Magento installation. After looking at the server logs, we found out the problem – permissions on index.php. The permissions on index.php were set to 664 meaning the group was able to write to the file. The minute we changed the permissions on index.php to 644 the store was working again.

Hope this helps 🙂

Categories
Blog Magento

Setting template for static blocks in Magento footer

Hi!
Today I had a task to insert static blocks into footer area of Magento web page. Since there are some troubles with WYSIWYG editor and html code I opted to make it more secure for future editing so I wanted to give the static blocks their template. I’m guessing that you know how to add static block into footer area. (Hint! Add it in local.xml).
In order for static blocks to be able to have template you have to call them as a type cms/widget_block instead of cms/block. This will allow your blocks to have template because by default static blocks don’t have a template. Here’s how the footer part of my local.xml looked like:

    <reference name="footer">
      <block type="cms/widget_block" name="cms_footer_socials" template="cms/footer_area.phtml">
          <action method="setBlockId">
               <blockId>identifier</blockId>
          </action>
      </block>
    </reference>

And in my theme I added cms/footer_area.phtml that with this code. Edit it to suit your needs:

<?php 
$id = $this->getBlockId();
$block = Mage::getModel('cms/block')->load($id);
?>
<div class="block">
    <div class="title"><?php echo $block->getTitle() ?></div>
    <div class="content"><?php echo $block->getContent() ?></div>
</div>

And now my static blocks in footer area have their template 🙂 .

Categories
Blog Magento

AW Blog different layout for posts view

Hi,
I had some trouble recently with Magento 1.7.0.2. and AW Blog. I couldn’t set different layout for blog posts view. My Blog listing needed to have 1-column layout and blog posts view 2columns-right layout.

Naturally I resorted to normal solution – add this lines inside aw_blog.xml file, in blog_post_view section:

// inside aw_blog.xml layout file
<blog_post_view>
    <!-- ... -->
        <reference name="root">
            <action method="setTemplate"><template>page/2columns-right.phtml</template></action>
        </reference>

        <reference name="content">
          <!-- ... -->
        </reference>
</blog_post_view>

Nothing happened.
After a bit of file searching I found AW_Blog_Helper_Post of AW Blog extension. I simply commented out a line at the end of renderPage function:

 // inside AW_Blog_Helper_Post of AW Blog extension

public function renderPage(Mage_Core_Controller_Front_Action $action, $identifier=null) {

/*...*/

  //$action->getLayout()->getBlock('root')->setTemplate(Mage::getStoreConfig('blog/blog/layout'));
  //above line was rewriting set layout in aw_blog.xml
  $action->renderLayout();

 return true;

And voila! It now changes the layout of blog posts view to my desired layout.

Hope this helps,
Iva

Categories
Blog Magento

Magento upgrade theme trouble

Magento + Upgrade == Lots of trouble.
Everyone who ever tried to upgrade their Magento store knows what I am talking about. Lots of (un)expected errors, troubles, headaches.
Such was the case with our upgrade. Recently we had a client who had a shop set on Magento 1.3.2.3 and wanted to upgrade to the latest version (at the time of writing the latest version is 1.7.0.2) because he bought a premium theme that only worked on Magento 1.7.x version.
We did the upgrade and it worked, with no trouble and no errors at all or so we thought 🙂
“Its a miracle” I thought to myself, but our happiness was short lived.
As soon as we installed the new theme it didn’t work as intended, javascript and CSS where broken.
With Firebug I discovered that upon page reload some javascript and other files where missing.
The strange thing is we didn’t knew where he was requesting those files.
After many hours of searching we discovered that he was requesting them from the database but with Magento having 300+ tables the tricky part was finding out from which table.
After many hours of search we found out that the table responsible for this is core_config_data.
I emptied the table and refreshed the page. The theme loaded flawlessly, no more errors, but upon entering the admin area some settings where missing.
So in order to fix this we created a new database called “donor” and redirected our Magento project to it.

<code class="language-xml">
  <connection>
   <host><![CDATA[localhost]]></host>
   <username><![CDATA[root]]></username>
   <password><![CDATA[]]></password>
   <dbname><![CDATA[old]]></dbname>
   <initStatements><![CDATA[SET NAMES utf8]]></initStatements>
   <model><![CDATA[mysql4]]></model>
   <type><![CDATA[pdo_mysql]]></type>
   <pdoType><![CDATA[]]></pdoType>
    <active>1</active>
  </connection></code>
<code class="language-xml">
  <connection>
   <host><![CDATA[localhost]]></host>
   <username><![CDATA[root]]></username>
   <password><![CDATA[]]></password>
   <dbname><![CDATA[donor]]></dbname>
   <initStatements><![CDATA[SET NAMES utf8]]></initStatements>
   <model><![CDATA[mysql4]]></model>
   <type><![CDATA[pdo_mysql]]></type>
   <pdoType><![CDATA[]]></pdoType>
    <active>1</active>
  </connection></code>

Refreshing our homepage started a fresh Magento installation.
We completed the installation and dumped the core_config_data table from the “donor” database, and replaced our “old” core_config_data table with data from the “donor” table.
After we returned our database path to the “old” database and reactivated the theme our problems where solved.
I wrote this article in hope that it will spare you hours upon hours of frustration and suffering.
Good luck with your update 🙂