Raju Gautam

Zend Certified Engineer – PHP 5; Joomla, Web Service, Wordpress Developer


E-mail: raju@devraju.com
raju.rachana@gmail.com
Tel: +977-985-111-3638
405776
Daman Nepal Again
385956
Me @ Daman, Nepal
DSC01943
Himalayas: The view of North-East from Shimbhanjyang, Daman, Makwanpur.
DSC01905
Daman, Makwanpur: A view from View Tower @ Daman, Makwanpur.
DSCF1254
Jubhung-8, Gulmi: The view from my home in Gulmi.
DSC00237
My Village, Jubhung-8, Gulmi: This is my village where my original home is located.

About Me

Hello, this is Raju Gautam, a PHP/JavaScript Programmer, PHP/AJAX Developer, Perl Programmer, RoR Programmer. I have been working as a Web Programmer since 2005 as soon as I completed my graduation. Though I worked with different other script/programming languages i.e. Perl, RoR, ASP (traditional), Visual Basic 6 but I have to say that my specialization has been only in PHP, MySQL, JavaScript/Ajax Programmer in recent couple of years.

Joomla jLanguage Editor component updated

Posted by rajug On January - 11 - 2012 0 Comment

jLanguage Editor is Joomla back end component that enables the facility to edit the language files of different language pack of front end website. Initially it was developed for Joomla 1.5 and later on with release of 1.6 and 1.7, it is now available for latest versions of Joomla.

I have received some reviews and comments for this component. And I am trying my best to upgrade/add features as per the request and also fixing the bugs as pointed by the reviewers. Recently there was a request to add a feature for copying updated files to Override folder so that upgrade of Joomla language packs doesn’t overwrite the changes made. Also pointed one bug/issue that it was stripping the HTML tags. Now the issue has been fixed and added the feature to copy the updated language files to Overrides folder.

Updated:

- HTML tags are supported regardless of what tags are used. Since editing is performed in the administrator section, no validations are checked.
- Updated files will be stored in the override directory so that when upgrading the Joomla core will not overwritten the modified texts/language content.

Thanks Janaf for pointing the issues.

The latest and updated files can be downloaded from Joomla Extension Directory. Please do not forget to add a review when you install and use it.

Importing large SQL dump files into MySQL !

Posted by rajug On December - 19 - 2011 0 Comment

Though because of some quite good MySQL client software these days it has been quite easier to import and export the databases whenever required. But importing and exporting bigger files is quite difficult task for all. Specially, phpmyadmin (a web based popular application for browsing MySQL online written in PHP) rely on the PHP’s upload_max_filesize, memory_limit and post_max_size configurations in php.ini. So there are no other options to use command line MySQL somehow.

If there is access to the server via SSH, then by running some MySQL commands, we can export and import large databases as well.

Export

Exporting a single database:
mysqldump -u [dbuser] -p [dbpwd] [dbname] > dumpfile.sql

Export all the databases in the server (rare case though useful in local systems sometimes):
mysqldump -u [dbuser] -p [dbpwd] > dumpfile.sql

Export whole multiple databses:
mysqldump -u [dbuser] -p [dbpwd] –databases [dbname] [dbname] > dumpfile.sql

Exporting specific tables:
mysqldump -u [dbuser] -p [dbpwd] [dbname] [table1 table2]

Restore

Restoring database is mostly done from a sql dump file. The same filename dumpfile.sql will be used here.

Restore a database:
mysql -u [dbuser] -p [dbpwd] [dbname] < dumpfile.sql

Restore a bulk SQL with multiple database:
mysql -u [dbuser] -p [dbpwd] < dumpfile.sql

Zipped files to be imported:
gunzip < dumpfile.sql.gz | mysql -u [dbuser] -p [dbpwd]

Restore multiple dump files using cat command:
cat dumpfile1.sql dumpfile2.sql | mysql -u [dbuser] -p [dbpwd]

Note: if your database user password has some special characters, do not use the password in the command itself. Just leave -p without password and you will be asked to enter the password when you hit the enter key to execute the command.
Example:
mysqldump -u [username] -p [dbname] > [backupfile.sql]

VC6 Compiled PHP is no more available in PHP download!

Posted by rajug On December - 17 - 2011 0 Comment

Last week I wanted to upgrade my PHP 5.3.5 to 5.3.8 as I saw that it has been released with some security fixes. I usually download VC6 version of PHP as it is written clearly in the left hand side of the download page under “Which version do I choose?” to use VC6 compiled PHP if we are in apache.org’s apache as a web server.

But this time I could not find VC6 version of PHP download. I browsed a lot and tried to search VC6 compiled PHP because I had already apache installed in my laptop downloaded from apache.org. Today I found there is a line just below that information in the same page as follows:

Do NOT use VC9 version with apache.org binaries, VC9 versions of Apache can be fetched at Apache Lounge. We use their binaries to build the Apache SAPIs.

Then I read the released note at http://windows.php.net/ and find the lines:

Windows users: please mind that we do no longer provide builds created with Visual Studio C++ 6. It is impossible to maintain a high quality and safe build of PHP for Windows using this unmaintained compiler.

For Apache SAPIs (php5_apache2_2.dll), be sure that you use a Visual Studio C++ 9 version of Apache. We recommend the Apache builds as provided by ApacheLounge. For any other SAPI (CLI, FastCGI via mod_fcgi, FastCGI with IIS or other FastCGI capable server), everything works as before. Third party extension providers must rebuild their extensions to make them compatible and loadable with the Visual Studio C++9 builds that we now provide.

All PHP users should note that the PHP 5.2 series is NOT supported anymore. All users are strongly encouraged to upgrade to PHP 5.3.6.

So I am now going to download the apache from http://www.apachelounge.com/ and will then use VC9 compiled PHP. I will update in my blog once I did.

प्रहरी: यो बाइक कसको ?
चालक: मेरो सर !
प्रहरी: खै लाइसेन्स निकाल्नुस !
चालक: किन सर ?
प्रहरी: नो पार्किंगमा राख्ने अनि ‘किन ?’ भन्ने ? (अलि पर देखाउदै) नो पार्किंग को बोर्ड देख्नु भएन ऊ~~ त्यहाँ ?
चालक: ए, अगी (५ मिनट अगाडी) ३/४ वोटा बाइक थियो तेसैले सबै भन्दा अगाडी छेउमा ल्यायर पार्किंग गरेको सर, नो पार्किंग को बोर्ड त धेरै पर पो छ त सर ! २/३ मिनेट पनि भाको छैन, यो आगनको पार्किंग छैन रैछ, के गर्नु ?
प्रहरी: धेरै कुरा नगर्नुस, नो पार्किंग मा बाइक राखेर तपाइले सडक मा बाधा पुराउनु भएको छ, तपाइँ कारबाहीमा पर्नु भएको छ… खुरुक्क लाइसेन्स दिनुस, नत्र अरु पनि कारबाही होला !
(के हो त्यो अरु कारबाही भनेको फेरी, निहु खोज्ने हो भने आर्को लफडामा परियाला भन्ने डर)
महिला: (एउटा कालो पल्सर देखाउदै) त्यहाँ अझै एउटा बाइक छ, खोइ त तेस्लाई कारबाही ?
प्रहरी: त्यो बाइक मेरै हो, तपाईलाई कारबाही गर्न मैले पार्किंग गरेको हो, छिट्टो लाइसेन्स दिनुस भनेको, (निकै हत्तारमा देखिनु भयो सर, मानौ कि धेरै टाढा जानु छ सरलाइ मेरो लाइसेन्स लियर !)
चालक: ए, तेसो भए तपाइले गरेको पार्किंगले चाही सडकमा बाधा पुर्याउदैन ?
महिला: (गुन्गुनाउदै) उहाँहरु ले त जे गरे नि हुने होला नि !
प्रहरी: कति धेरै कुरा गरेको ? तपाइँ कारबाहीमा पर्नु भएको छ, खुरुक्क दिनुस लाइसेन्स !
चालक: (लाइसेन्स झिकेर दिदै) केहि गरि मिलाउनुस न सर, हुन्न ? एकपटकलाइ गल्ति भयो अरुको पछी लाग्दा (हुन त अरु बाइक भन्दा अगाडी नै लगेर राखियको थियो) !
प्रहरी: (चिट दिदै), हुन्न, भोलि बग्गीखाना लिन आउनुस, तपाइको लाइसेन्स उतै जान्छ !
चालक: (चिट हेर्दै) हैन यसमा त कमलपोखरी लेखेको छ त !
प्रहरी: पक्रेको कमलपोखरी हो, लिन आउने चाही बग्गीखाना !
चालक: खोइ कतै लेखेको छैन त ?
प्रहरी: मैले भने त उतै आउनुस, तेस्मा लेखेको पढ्नुस के के लेखेको छ !
(के नै लेखेको रैछ भनेर हेरेको के हुनु उसको नाम पोस्ट लेखेको रैछ, अनि कसुर चाही ‘सडक पार्क स.अ. बाधा’ रे)

मिति: २०६८, आषाढ २८ गते दिउसो ३ बजे तिर
स्थान: कमलपोखरी, हिमाल नर्सिंग होम अगाडी आँगनको गेट !
पात्रहरु :
प्रहरी: काजी उप्रेती (दर्जा – प्र. ज. – ट्राफिक प्रहरी)
चालक: म आफै (राजु गौतम)
महिला: मेरो श्रीमती

Today I got an email saying in the subject line ‘You requested a new Facebook password’ and with the following email body part:
—————————————————————————–
Hi Raju,

You recently asked to reset your Facebook password. To complete your request, please follow this link:

https://www.facebook.com/recover.php?n=xuhpXzatX&id=520903088&s=10

Alternately, you may go to https://www.facebook.com/recover.php and enter the following password reset code:

xuhpXzatX

Please note: for your protection, this email has been sent to all the email addresses associated with your Facebook account.

*Didn’t Request This Change?*
If you did not request a new password, let us know at:

https://www.facebook.com/login/recover/disavow_reset_email.php?n=xuhpXzatX&id=520903088

Thanks,
The Facebook Team

—————————————————————————–

And I was just wondered why and when I did request for resetting the facebook password. I never did that as far as I remember. And I just tried to login with my existign password and I was able to login. Thank god. This is again an SPAM. The spammers are with new route now. Facebook users are not almost awere of fake links to be clicked in the Facebook itself and they have now tried a new way by sending the links to their email address. As you can see above in the body part, they have asked to click on a link which MUST be a fake link or it MUST do an andesirable thing. I am not sure what exactly it does because I haven’t clicked it yet. But as far as I know the link does not even exists so I don’t think that it will do anything dangerous but to be safe it is good not to click on the links.

Seeing the email’s header part, we can say that it is the fake one:
Mail header:
————————————————–
from Facebook password+ys2yzf6@facebookmail.com
reply-to Facebook to Raju Gautam
date Thu, Jun 30, 2011 at 7:56 PM
subject You requested a new Facebook password
mailed-by facebookmail.com
signed-by facebookmail.com

————————————————–

28444

Joomla manages the contents mainly in two ways; one is from database and the other is using files. Contents stored in the database are easily editable from Joomla back end but it does not have any feature to edit language files and their contents from back end. From my 4 years of Joomla development experience, I have been asked many times by the clients to edit the languages texts stored in the files. Some clients do not know how to use FTP, some of them do not even have any FTP client software installed in their computers and some really do not want to do so themselves. So for some reason, they must always ask the developers to edit the texts even if it is a single piece.

j!LangEditor is the solution of above problem. This is the Joomla back end component which lets the content manager (or any user that can login to Joomla back end) to edit the langauge files of Joomla website (not administrator) without using FTP software. Before this, they have to login using FTP and edit the file and reupload the file to the server. j!LangEditor allows to edit the content of any language files from Joomla back end itself.

Previously, the extension was developed for Joomla 1.5 but now I have developed a separate component for Joomla 1.6 because there are slight changes in the structure and coding in Joomla latest 1.6.

Uses:
- Download the zipped extension.
- Unzip the package and you will have two zip:
– com_jlangeditor-1.0-Joomla-1.5.zip for Joomla 1.5
– com_jlangeditor-1.1-Joomla-1.6.zip another for Joomla 1.6.
- You can now install your desired/required version.

In next release, I will try to manage default website language to be loaded by default or set some parameter.

The extension has been already approved and listed in Joomla Extension Directory under > Languages > Automatic Translations .

Note: It will try to fetch the files of en-GB for the first and if there is no English language then nothing will be listed. You will have to choose the language from the drop down.

Enjoy editing the language files without opening FTP!!!

Since Magento itself is too vast not only because of its features but also because of heavy number of files within it, it is really difficult to find which file is being used for what purpose and where that file is really located.

Front End:
Magento has provided a feature in its configuration section in admin that allows us to enable template path hints. If we enable it, it will shows the file pathand block names.

To enable it:
1. Login to admin.
2. Go to System->Configuration.
3. Select a website from and click Developer tab in left.
4. In the Debug section, select Yes for Template Path Hints & Add Block Names to Hints.
5. Save configuration and refresh the front end page you will have some red blocks to indicate what files files are used in which block along with Block (class names) used.

Magento Template Path Hints Without Changing in Admin:
But enabling and disabling it from back end is boring in time to time. So I thought why not just enable the hints with some values passed via URL like http://www.mymagentosite.com/?template_hint=true or something like this. I searched where actually Magento handles this and found at app/code/core/Mage/Core/Block/Template.php. There is a method called getShowTemplateHints() at around line number 176 which handles it. The function originally looks like this:

public function getShowTemplateHints()
{
	if (is_null(self::$_showTemplateHints)) {
		self::$_showTemplateHints = Mage::getStoreConfig('dev/debug/template_hints')
			&& Mage::helper('core')->isDevAllowed();
		self::$_showTemplateHintsBlocks = Mage::getStoreConfig('dev/debug/template_hints_blocks')
			&& Mage::helper('core')->isDevAllowed();
	}
	return self::$_showTemplateHints;
}

So the two static members (self::$_showTemplateHints & self::$_showTemplateHintsBlocks) of the class are to set to handle them. So I modified it to be something like this:

public function getShowTemplateHints()
{
	if (is_null(self::$_showTemplateHints)) {
		self::$_showTemplateHints = Mage::getStoreConfig('dev/debug/template_hints')
			&& Mage::helper('core')->isDevAllowed();
		self::$_showTemplateHintsBlocks = Mage::getStoreConfig('dev/debug/template_hints_blocks')
			&& Mage::helper('core')->isDevAllowed();
	}

	// overwrite the template hit
	$th 	= Mage::app()->getRequest()->getParam('th', false);
	$token 	= Mage::app()->getRequest()->getParam('token', false);
	if($th == 1 && $token == 'PHP'){
		self::$_showTemplateHints = true; // for template path
		self::$_showTemplateHintsBlocks = true; // block names
	}

	return self::$_showTemplateHints;
}

I have used two variables for security. Now if ‘th’ and ‘token’ are set with specific values then both of the static members are set to true and hence the templates will be now visible. Now if you hit something like this in your browser http://www.mymagentosite.com/?th=1&token=PHP you can see template hints and added Block Names. I found this quite handy rather than going to admin and enable/disable.

Admin:
For admin, there is no direct feature, so there is a trick direcly modifying the database table and values. This I had found in the internet. You need to add two rows in the table ‘core_config_data’ as follows for the first time:

INSERT INTO core_config_data (scope, scope_id, path, value) VALUES
('default', 0, 'dev/debug/template_hints', 1),
('default', 0, 'dev/debug/template_hints_blocks', 1);

If you have already those rows then you just need to update the ‘value’ field with 1 to enable and 0 to disable.
Disable:

UPDATE core_config_data SET value=0 WHERE scope='default' AND scope_id = 0 AND path ='dev/debug/template_hints'

Enable it again:

UPDATE core_config_data SET value=1 WHERE scope='default' AND scope_id = 0 AND path ='dev/debug/template_hints'

Hope this will help :-) .

Magento Admin shows 404 page

Posted by rajug On March - 7 - 2011 0 Comment

Though I am still new and have to learn a lot in Magento but I am struggling for Magento’s some serious issues of our clients. Among the so many problems with working experience in Magento, one of our customer encountered a database table corrupt problem and he asked the technical guy in their server to fix the problem. The technical person just repaired the database and the the Magento front end site worked perfectly fine. But when we try to go to admin of the shop, then it always shows the 404 page instead of showing the Admin login form.

After some research, I came to know that it is something about the store view for admin section which is supposed to be in the ‘core_store’ table. When the database was repaired, two rows were inserted (or updated) as follows:

--------------------------------------------------------------------------
`store_id`,`code`,`website_id`,`group_id`,`name`,`sort_order`,`is_active`
--------------------------------------------------------------------------
'2', 'admin', '0', '5', 'Admin', '0', '1'
'1', 'default', '0', '5', 'Admin', '0', '1'
--------------------------------------------------------------------------

I just compared with another Magento shop and there was ’0′ as stored_id for admin. And I just edited the row and put it as ’0′ instead of ’2′ and saved it.

Now the Admin section worked like a charm !

Strange problem but easy fix (after a research of 3/4 hours) !!

Just shared it hoping it will help others encountering the same problem :-)

In last December I had decided to upgrade my laptop to be up to date with the technologies. So I formatted the previous installation of OS and then installed Windows 7. Thanks to my cousin (Bhuwan Sharma) in the USA for the Windows 7.

Then I just installed normally all the programs and applications including latest Apache (2.2.17), PHP (5.3.5) and MySQL (Community 5.5.8). The installation went quite good for all. and some of the previous projects done worked successfully. But after a couple of days, I tried to install Joomla 1.5.22 and I found the following error after I submit fourth step “Database Configuration” with database details:

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'TYPE=MyISAM CHARACTER SET `utf8`' at line 29 SQL=CREATE TABLE `jos_banner` ( `bid` int(11) NOT NULL auto_increment, `cid` int(11) NOT NULL default '0', `type` varchar(30) NOT NULL default 'banner', `name` varchar(255) NOT NULL default '', `alias` varchar(255) NOT NULL default '', `imptotal` int(11) NOT NULL default '0', `impmade` int(11) NOT NULL default '0', `clicks` int(11) NOT NULL default '0', `imageurl` varchar(100) NOT NULL default '', `clickurl` varchar(200) NOT NULL default '', `date` datetime default NULL, `showBanner` tinyint(1) NOT NULL default '0', `checked_out` tinyint(1) NOT NULL default '0', `checked_out_time` datetime NOT NULL default '0000-00-00 00:00:00', `editor` varchar(50) default NULL, `custombannercode` text, `catid` INTEGER UNSIGNED NOT NULL DEFAULT 0, `description` TEXT NOT NULL DEFAULT '', `sticky` TINYINT(1) UNSIGNED NOT NULL DEFAULT 0, `ordering` INTEGER NOT NULL DEFAULT 0, `publish_up` datetime NOT NULL default '0000-00-00 00:00:00', `publish_down` datetime NOT NULL default '0000-00-00 00:00:00', `tags` TEXT NOT NULL DEFAULT '', `params` TEXT NOT NULL DEFAULT '', PRIMARY KEY (`bid`), KEY `viewbanner` (`showBanner`), INDEX `idx_banner_catid`(`catid`) ) TYPE=MyISAM CHARACTER SET `utf8`

I could not find anything particular solution for the solution with some limited words in the Google but I came to a decision that it must be something because of engine type. Then I created a test table in test database and then saw the structure of that table and noticed there was something:

CREATE TABLE `tbltest` (
  `id` int(11) NOT NULL auto_increment,
  `title` varchar(255) NOT NULL default '',
  INDEX `mytestindex`(`id`)
) ENGINE=MyISAM;

I just noticed there ‘ENGINE=MyISAM’ but when I opened the Joomla’s installation sql file (Joomlafolder/installation/sql/mysql/joomla.sql) and noticed that there was TYPE=MyISAM. So I just find and replaced all the occurrences of ‘TYPE=MyISAM’ to ‘ENGINE=MyISAM’ and tried to install Joomla then it worked like a charm.

So I came to the conclusion that TYPE keyword is no more used with MySQL latest (5.5.8) versions. This has been posted as a bug here http://bugs.mysql.com/bug.php?id=59288 but they claim that it is not the bug. The keyword ‘TYPE’ was introduced as deprecated since ENGINE was added in MySQL 4.0.18. And it is clearly mentioned in the CREATE TABLE structure manaul page (http://dev.mysql.com/doc/refman/4.1/en/create-table.html) that the TYPE keyword will be removed in future versions.

This is my experience. I was about to share this right in the first week of January when I noticed this but was quite busy and forgot :-)

Magento has lots of features as an ecommerce application. No doubt that’s why it is too popular too. These days most of the clients (end customers/users) prefer Magento by themselves. But there are some pitfalls within it. Once explore it specialy working as a developer (programmer), you will be in a trouble in such way that you are no more going to use Magento for any purpose because you will stucked in such a problem which neither can be solved nor you can directly change Magento’s code itself. Saying so, I don’t mean that we cannot solve those problems. Indeed we can solve the problems sometimes by hacking the core codes and in the other times by changing some values directly from the database. Since Magento is designed and developed with EAV (Entities, Attributes & Values) model, it is really difficult to find a particular data/value within the database too. And most of the times we extend its features by creating our own modules.

Anyway, here I am going to present a hack to solve a problem.

Problem:
For SEO friendly URLS, Magento has a field for a Product and Category to create custom SEO friendly URL keys. But when you have multiple stores, then you cannot normally have different URL keys for different stores because the field url_key is ‘GLOBAL’ by default. For products, you can update the url_key attribute’s is_default field to ‘Store Views‘ from Attribute Management. But for the category’s url_key field, you don’t have that option in Magento. But the field does exist in the database with the same attribute code but having different backend_model so you need to go to the database directly and change the ‘is_global’ field 1 to 0.

Solution:
- First of all, access your Magento database from phpmyadmin (or any MySQL client).
- Then run the following query:

SELECT * FROM eav_attribute WHERE attribute_code LIKE '%url_key%';

- Then you will have following results:

479	9	url_key	NULL	catalog/category_attribute_backend_urlkey	varchar			text	URL key
481	10	url_key	NULL	catalog/product_attribute_backend_urlkey	varchar			text	URL key

- First attribute is for the category and second one is for the products. So note down the attribute_id of the first record (in my case 479).
- Then run the following query:

SELECT attribute_id, is_global FROM catalog_eav_attribute WHERE attribute_id=479;

To make sure if it has ’1′ by default or not because ’1′ is the value to make the attribute GLOBAL.

- If it is ’1′ then run the following query to update the value to ’0′:

UPDATE catalog_eav_attribute SET is_global='0' WHERE attribute_id=479;

- Now clean the cache and try to edit a category with different stores and see the field URL Key. This will now have ‘Store View’ scope.

Enjoy the SEO friendly URLs for categories too :)