• Posted on
    May 24, 2017
  • Tags
     
  • Author
    Silpion

Gitmodule is a powerful feature for keeping all project git hosted repos on their original repositories.

For Magento 1 usage along with modman deployment process it takes following commands:

git submodule add https://github.com/lcbrq/magento-LCB_Faq.git LCB_Faq
git submodule init

modman deploy LCB_Faq

Next, after adding symlinks to .gitgnore file the submodule info could be safely pushed to repository.

git add .modman/LCB_Faq
git add .gitignore
git add .gitmodules

git commit -m “Add LCB_Faq plugin as project submodule”

In your repo the data would be shown as something like Subproject commit ea7099ee02ab3593fe7ae59ee7ec129c54749ec8 instead files.

  • Posted on
    May 17, 2017
  • Tags
     
  • Author
    Silpion

Today I’ve struggled with very unusual hack. I’ve got a request from my partner to fix one of his clients Magento stores recently listed on Google as hacked site.
My antimalware tools showed nothing wrong in the code, I’ve found nothing wrong in the git repository (later it appeared that the buddy before committed the malware with git add -A from server).

There was nothing wrong with the SEO content in the source code. Usual meta name and description but fetching the site in Google Webmaster tools as Google showed some Viagra etc. words there.

I’ve realized finally, that the hack is good enough to stay visible only for robots which I’ve managed to debug quickly using:

curl -sD – -L -A "Mozilla/5.0 (compatible; Googlebot/2.1;  +http://www.google.com/bot.html)" http://somewebsite.com/customer/account/login/

Indeed, the site content was completely different for human visitor and Google robots indexing the store. Debugging file after file from template to controller and repeating the curl call I’ve found out that app/Mage.php had an addition:

@include_once BP . DS . 'app' . DS . 'etc' . DS . 'modules' . DS . "include.php";

Replacing site content only for robots.
Damn people, always watch what you commit from the server to the repo.

“Share” any kind of data to all views within a controller in Laravel framework

public function __construct()
    {
        //Get from Database some options, for example the header and title of your site
        $site_options = Admin::where('status','active')->first();
        $header = $site_options->site_header;
        $title = $site_options->site_title;

         $data = [
                'site_header'=>$header,
                'site_title'=>$title
                 ];

        view()->share('data_view',$data);
    }

for example set header and title from an active options set.

We had small issue with Cron not working on one of freshly installed Magento 2 store last days. First of all, it’s often to forgot that M2 cron setup requires more than one entry, for not only php /bin/magento cron:run but also php update/cron.php to get rid of that annoying “Cron not working” message readiness check in Component Manager.

Later, checking it manually I’ve found out that php update/cron.php call throws out:

PHP Fatal error: require_once(): Failed opening required '/home/www-data/magento2/update/vendor/autoload.php' (include_path='.:/usr/share/php') in /home/www-data/magento2/update/app/bootstrap.php on line 13 

The repository cloned didn’t have the update packages installed and to solve it it was necessary to run composer install not only in the Magento2 root directory but also update subfolder.

Unusual subfolders (not subdomains) M2 setup can be achievied exactly same way M1 was done.
First of all, create store in your Magento 2 admin, then directory folder.
Two files are required for the operation. Index.php and .htaccess copied from your store.
To run certain M2 store view, it’s enough to replace:

$bootstrap = \Magento\Framework\App\Bootstrap::create(BP, $_SERVER);

with

$params = $_SERVER;
$params[\Magento\Store\Model\StoreManager::PARAM_RUN_CODE] = 'your_store_code'; $params[\Magento\Store\Model\StoreManager::PARAM_RUN_TYPE] = 'store';
$bootstrap = \Magento\Framework\App\Bootstrap::create(BP, $params);

Then, set the store url as for subfolder and what’s most important – set base url for static view files to:

example.com/pub/static

and base url for media to

example.com/pub/media

Where example.com is of course your main domain name for the store.

Valid configuration for Nginx can be alike:

location ~ ^/(?<uri_prefix>(en)) {
    rewrite / /$uri_prefix/index.php break;
    echo_exec @phpfpm; 
}

location ~ ^/(?<uri_prefix>(fr)) {
    rewrite / /$uri_prefix/index.php break;
    echo_exec @phpfpm; 
}

SELECT
o.grand_total AS 'Order Total',
o.created_at AS 'Payment Day',
p.method AS 'Payment Method',
CONCAT_WS(' ', o.customer_firstname, o.customer_lastname) AS 'Customer Name',
o.increment_id AS 'Order Number'

FROM sales_flat_order o
LEFT JOIN sales_flat_order_payment p ON p.entity_id = o.entity_id
WHERE (o.created_at BETWEEN '2016-01-01' AND '2016-12-31')

Thank’s to the Hypemedia teamwork we managed to discover very dangerous bug in IWD_ProductLabel 1.4.0 plugin.
The module adds modal on admin pages with some not unique ids like `size`. Because of that, mass attributes update marking attributes not to update via javascript could get unblocked targeting wrong id=”size” node while having one of the following on the store: bg, size, color and padding specified in app/design/adminhtml/default/default/template/productlabel/modal.phtml

The solution to fix it can be very simple. Seems that these IWD productlabel ids are used only to target input for label properly so change them to stay different that any attribute used in your shop.
Here’s the sample git diff:

-
<label for="bg">Bg color</label>
-
<input id="bg" class=" input-text" name="text" type="text" value="" />
<p class="note"></p>
&nbsp;
+
<label for="iwd_productlabel_bg">Bg color</label>
+
<input id="&quot;<br" class=" input-text" name="text" type="text" value="" /> 

Well, we couldn’t figure it out for a while then, suddenly it was clear that PHP allows for a new self directive.

foreach($array as $item){
$entity = new self;
$entity->name = $item->name;
$entity->save();
}
  • Posted on
    September 7, 2014
  • Tags
     
  • Author
    Silpion

Today, we’ve finally managed to complete our Woocommerce to Magento migration tool. We consider Magento migration a good choice for more demanding customers, offering a fast migration service involving products, attributes and categories.

As the Magento is developed as the ecommerce engine and the Woocommerce is an addon to the great WordPress page/blog cms we always try to research consumers’ needs and the sales concept.

After some brand register related task, we are happy to announce our website launch

Fork us on GitHub