This Magento extension provides a Real Full Page Caching for Magento powered by Varnish with support of Session-Based information caching (Cart, Customer Accounts, ...) via ESI includes

Overview

Magento-Varnish

This Magento extension provides a Real Full Page Caching (FPC) for Magento powered by Varnish with support of Session-Based information caching (Cart, Customer Accounts, ...) via ESI includes

Table Of Content

  1. Synopsis

  2. Requirements

  3. Step by Step installation

  4. Caching Policies - How to define what's cached and what's not?

    4a. Where do you define a caching policy?

    4b. How to define a caching policy on a block

    4c. List of the different parameters defining a caching policy

    4d. How to "flush" the cache

    4d-1. [Flushing Varnish via Magento](#flushing-varnish-via-magento)
     
    4d-2. [Flushing Varnish cache via command line](#flushing-varnish-cache-via-command-line)
    
  5. How does the extension work basically?

  6. Important notes

  7. Why redis?

  8. Known bugs

  9. TODO

  10. Lectures

  11. Apologies

  12. Contact

  13. License

Synopsis

Tired of fake Full Page Cache Magento extensions? Tired of these extensions promising to make your website fly, shooting to the stars, but barely reaching sea level?

This extension is for you.

Magento-Varnish:

  • Fully Caches your pages
  • Fully Caches pages with session based content (for example, your customer cart) thanks to ESI includes
  • Allows different caching rules for different blocks in the same page (you can have a block expiring after 10 minutes, another block expiring after 3 days, another after 15 seconds, and so on) thanks to ESI Includes
  • Automatically refreshes session based pages when needed (for example, your customer adding an item to its cart)
  • Refreshes product page cache on product save
  • Refreshes category page cache on category save
  • Refreshes product page when a product goes out of stock
  • Refreshes CMS page after save
  • Makes your website fly

Requirements

Step by Step installation

  1. Install Varnish on your server

  2. Install Redis on your server

  3. Install phpredis on... your server, you got it.

  4. Configure your webserver to listen on port 8080. If you can't use this port, you'll have to make some changes in our configuration. We'll get to that later.

  5. Connect on your Magento admin area and disable all caches in the "Cache Management". This Step is very important.

  6. Clone this repository and copy and paste the app/ and lib/ directory into your Magento installation

    note: this extension overrides Varien_Cache_Core and Credis_Client by creating a file in app/code/local/Varien/Cache/Core.php and app/code/local/Credis/Client.php. Read more about these Core Overrides in the Important Notes section at the end of this document.

  7. Configure Varnish to use the configuration file provided with the extension. You will find this file in your Magento directory in app/code/local/Betabrand/Varnish/vcl/magento.vcl

    6b. If your webserver is not configured to listen on port 8080, modify the magento.vcl, line 76. Replace .port = "8080" by your port.

You're halfway done!

Connect with your browser to your webserver and see if your Magento installation works. If your page doesn't load, you get an error message, or any abnormal behavior, verify that everything is configured correctly. You just installed a bunch of software, chances are that you'll have a problem somewhere.

If everything went well, you should see your Homepage.

Let's keep going:

  1. Connect to your Magento administration area (most likely to be http://yourhost/admin)

  2. Go in System->Cache Management and disable every cache

  3. Go in System->Configuration->General->Varnish->Module Activation and set "Enable Varnish Module" to yes and click save

    note: Once you set this to yes and save, you will certainly notice that "Enable Varnish Module" stayed set to no. That's normal! Don't spend hours trying to set it to yes, just go on to the next step.

  4. Go back in System->Cache Management and click the "Flush Cache Storage" button.

Caching Policies - How to define what's cached and what's not?

A caching policy defines what is stored in cache, how it is cached and how for long.

A caching policy is defined on a block ( ) or a reference ( ). However, you can only set a policy on a block that extends from Mage_Core_Block_Template. On a given page, different caching policies can be applied to different blocks.

By default, the extension caches everything. This means that each time a client visits a URL, the content of the page is put in cache and every subsequent HTTP request to the same url will be served the cached content.

Where do you define a caching policy?

Your caching policies are defined via the Magento layout files, just like your .

How to define a caching policy on a block

It's easy!

First, remember, by default, the extension caches everything.

If you had some session based information showing on the page (the number of items in your cart for example), this information is cached and every other client accessing the same URL will see the exact page you saw, telling them they have x items in their cart, even if they don't have any! You will notice however, that the cart information is not cached! How is that possible? Well, that's because the extension by default defines a specific caching policy for the cart block stating that the "cart information" should be cached, but, on a per-client basis. You can find this policy in the frontend varnish.xml layout file.

Ok, so how do you define a caching policy?

Let's use this predefined policy as an example.

Open the frontend varnish.xml layout file. Line 12 you can read:

per-client ">
    
   
		
    
        	
     
        		
      
       per-client
      
        	
     
        
    
	
   

The instructs Magento that we want a specific caching policy on the cart_sidebar block. The cart_sidebar block is defined in the base layout file checkout.xml. The caching policy for this block is defined in the node. The node contains all the parameters defining our caching policy.

In this case, we only have one parameter called . This parameters indicates to Magento which type of caching we want on the block. In this case, the type of caching is per-client. per-client means that we want Varnish to cache a different version of the for each client.

List of the different parameters defining a caching policy

Given the example above

per-client | per-page | global 1w 7d 168h 10080m 604800s current_product, current_category, my_custom_registry_key1, my_custom_registry_keyN ">

   
	
    
    	
     
    		
      
       per-client | per-page | global
      
    		
      
       1w 7d 168h 10080m 604800s
      
    		
      
       current_product, current_category, my_custom_registry_key1, my_custom_registry_keyN
      
    	
     
    
    

   

: Can take one and only one of the following values

	per-client	: one version per client is stored in cache (the session cookie identifies which client gets which cached version of the block)
	per-page	: one version of a block is stored per URL of a page (the url of the page determines which cached version of the block is served to the client)
	global		: one version of a block is stored for the entire website (only one cached version of the block exist and it is served to every client)

: Is a Duration like

	1w (1 week)
	3d (3 days)
	3600s (3600 seconds)

If no expiry is set, by default it will be set to 3d (3 days), or 10m (10 minutes) if the cache_type is per-client. (We set the per-client cache expiry to 10 minutes because it would not make sense to keep this data for 3 days).


: Registry keys is a very special parameter, that I consider more like a Hack than a feature. It allows you to specify a set (1 or more) of registry keys (you know, Mage::registry() and Mage::register()) that your is using. You can set 1 or multiple values. In case of multiple values, just separate them with a comma.

	current_product
	current_product, current_category

How to "flush" the cache

Flushing Varnish via Magento

You can flush the "Varnish" cache by going in your Magento Admin in System->Cache Management.

By selecting "Varnish" in the "Cache Storage Management" and hitting "Refresh" you will blow away the entire cache. You rarely need to do that.

If you need to refresh a product page, or a category, or a CMS page, just "Edit" the product, category or CMS and "Save". The action of "Saving" automatically triggers a cache refresh for this specific page.

When a product goes out of stock, its page is automatically refreshed.

Flushing Varnish cache via command line

You can also flush your cache via the Varnish command line varnishadm

How does the extension work basically?

This extension works by adding an Event listener to core_block_abstract_to_html_before. This event is dispatched by Magento just before rendering the HTML for a block.

When the extension intercepts the event, it checks if a caching policy has been defined on the block that is being rendered. If yes, the extension replaces the actual template file associated to the block with its own template varnish/esi.phtml.

This template renders only one HTML line .

This ESI include is then detected by Varnish which will make an HTTP request to the URL defined in the src attribute of the esi:include.

The request will always go to a URL of the form 'varnish/cacheController/getBlock/cacheType/xxx/expiry/xxx/fingerprint/xxx'.

The CacheController receives the request and returns the actual HTML of the block.

On the Varnish side, I wrote a specific configuration meant to work with this Magento extension.

Important notes

  • You should consider this extension as a beta, not suitable for production use
  • I wrote this extension on Magento 1.6.1.0, with only one store, and did not test it on any other version, nor on a multistore system. some users reported versions 1.4 - 1.5.1.0 - 1.6.2.0 - 1.7.0.2 to be working.
  • I tried to minimize as much as I could Core Overrides.

Core overrides are a huge pain for developpers and should be avoided: they cause conflicts, make the code hard to maintain and debug.

However, because some parts of the Core are very old and have been written by what I suspect being "Unpaid Interns", I had to override Mage_Core_Block_Message and Varien_Cache_Core.

I also overrided the Credis_Client because of a bug. When the close() function is called by the destructor, sometime an exception is thrown causing a message to show up Fatal error: Exception thrown without a stack frame in Unknown on line 0. In order to avoid this to happen, I added an ugly try-catch somewhere line 290.

Core overrides are most of the time completely avoidable and I still don't understand why so many extensions use them when a simple Event Listener would do the trick, but that's another topic.

  • This extension comes with some default policies. You will certainly don't need to change them. You can find them in the varnish.xml layout files (1 varnish.xml for the frontend area, and one varnish.xml for the admin area).

  • At the moment, this extension does not allow caching of any part of the Magento admin area. Trying to define a caching policy for a defined in the admin layout will failed and throw an exception.

  • Finally, this extension is still in development and by no mean can it be considered stable. However, it is stable enough to be released and any help to make it better is welcome! Feel free to send pull requests, bug fixes and feature requests!

Why Redis?

Redis is used to get around the fact that there's no context persistency between request in PHP. Thus, redis is used to store datas needed by some ESI Includes.

For example, when a caching policy specifies some to keep, the content of these registry keys is stored in redis and retrieved by the ESI request.

Why not storing these in a database table?

My first iteration was using a database table. I decided that this solution was not optimal. However, a feature to develop would be the ability for one to choose his storage via adapters for Memached, MySQL, Redis, File, etc, just like the Magento cache system.

Why not using the Magento Cache System, you idiot?

Well, good question. First, this extension wasn't supposed to be open-sourced when I begun developping it, so nobody was supposed to see the mess. Then, I needed a system that would allow me to list all the ESI includes by cache_type, block_type and block_name. As I said earlier, I first used a database table, but I found that solution to be too complicated and not optimal. I started looking at using the Magento Cache and use "tags" to be able to filter the data. However, I was using Memcached and it doesn't support tags, I could have used the filesystem, but I didn't want because of how slow it would have been. I decided to use redis as it solved all my problems: no database, no table to create and no SQL, no slow access, easy access of my data thanks to the tags.

Now, when I look at it, I see multiple problems with the current implementation of the code:

  • First, I made the choice to store everything about the cached block in redis. Meaning that the loss of the information stored in redis is equivalent to the loss of an ESI Include.

    As a matter of fact, when a caching policy is defined on a block, the code generate a unique URL for this block.

    This URL is made unique via a "fingerprint" calculated by the injectEsi() function.

    All the data related to this block (name of the block in the layout, store_id, design_theme, design_package) is then saved in cache with the fingerprint as key.

    This fingerprint is then read by the "CacheController" and the data defining the block is pulled out of the cache.

    Now, if the redis cache is emptied, or the key (finrgerprint) evicted, next time the ESI request is made, the code will return nothing because it won't be able to retrieve the data from the cache.

    My first implementation was relying on parsing the URL. All the data needed to generate the HTML for an ESI request was available directly in the URL, and redis was used only to store registry_keys.

    I moved away from this because the URL were becoming very long and the code hard to read, but I didn't think about the consequences of the lost of data in redis.

    I may move back to my previous iteration.

  • Secondly, it should be left to the final user to decide how to store the data. Restricting to redis is not optimal.

Known bugs

  • In the Customer Accounts, when you click on "My Orders" the caching policy applied to the "sales.order.history" block generates an exception: Fatal error: Call to a member function setHeaderTitle() on a non-object in /app/code/core/Mage/Sales/Block/Order/History.php on line 52

If you want to fix this bug, either you have to remove the caching policy, or, you need to override Mage_Sales_Block_Order_History and comment out line 52. It's ugly, but not my fault!

  • The same type of bug occurs on the Account Dashboard when you uncomment the caching policy applied on "customer_account_dashboard". In order not to scare people away from the extension by facing almost immediately an exception, I commented out the caching policy.

If you want to uncomment the caching policy, you'll have to override Mage_Customer_Block_Form_Register and comment out line 43. Again, it's ugly, but not my fault!

TODO

  • Remove some other dirty lines of code
  • Translate and use $this->__("")
  • Finish coding/debugging the Cache Management area allowing to flush "per-page" cached block. With the current implementation when there's a lot of "per-page" block, the page takes for ever to load.
  • Once the previous item is done, allow to flush "global" blocks as well
  • Allow more system configuration in general (like enable/disable cache refresh on save, or on out of stock)
  • Correct every typos in comments and doc
  • Complete the doc with some schema of the interaction between Varnish and Magento
  • Create an API to access this extension from other modules and Document this API

Lectures

Apologies

I apologize to Shakespeare for any typos, grammatical errors or bad syntax you may have encountered in this document.

Contact

Don't hesitate to contact me by email at [email protected] and send me your suggestions or whatever goes through your mind

LICENSE

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program.  If not, see 
   .

Author: Hugues Alary 
   

   
Comments
  • Flushing cache provides to error

    Flushing cache provides to error

    There was an error when refreshing: Error 405 Not allowed. Not allowed. Guru Meditation: XID: 48798421 Varnish cache server

    Why flush is restricted? What need to check ?

    opened by devzorg 3
  • [Enhancement] Prevent the administration area from being cached

    [Enhancement] Prevent the administration area from being cached

    In the varnish configuration (vcl) file look for the following:

    if(beresp.http.X-Magento-DoNotCache == "1")
    

    and replace it by

    if(beresp.http.X-Magento-DoNotCache == "1" || req.http.Cookie ~ "adminhtml")
    

    This will make sure that there is no caching if you are logged in and have the adminhtml cookie.

    opened by kdckrs 3
  • Customer layout handles no longer work

    Customer layout handles no longer work

    When using this module the login/logout links wouldn't show anymore so I went to debug.

    Apparently the following handles that you can find in customer.xml are no longer working: <customer_logged_in> and <customer_logged_out>

            <reference name="top.links">
                <action method="addLink" translate="label title" module="customer"><label>Log In</label><url helper="customer/getLoginUrl"/><title>Log In</title><prepare/><urlParams/><position>100</position></action>
            </reference>
        </customer_logged_out>
    

    Doesn't add the login link, same goes for the logout link.

    Would be great if you had any solution for this ;)

    Thanks, Kenny

    opened by kdckrs 2
  • Warning: uasort() expects parameter 2 to be a valid callback, no array or string given in app/code/community/Betabrand/Varnish/Block/Adminhtml/Cache/Perpage/Grid.php on line 46

    Warning: uasort() expects parameter 2 to be a valid callback, no array or string given in app/code/community/Betabrand/Varnish/Block/Adminhtml/Cache/Perpage/Grid.php on line 46

    The following warning is generated in the system.log when visiting the Cache Management page in the administration area:

    Warning: uasort() expects parameter 2 to be a valid callback, no array or string given in app/code/community/Betabrand/Varnish/Block/Adminhtml/Cache/Perpage/Grid.php on line 46
    
    opened by kdckrs 1
  • [Fix] Caching mechanism doesn't take store-specific URL into consideration

    [Fix] Caching mechanism doesn't take store-specific URL into consideration

    When you have a Magento setup as below where each store has it's own URL:

    http://domain.com/nl/ http://domain.com/fr/ http://domain.com/en/

    Something goes wrong when a certain block is cached it caches it without the nl, fr or en suffix. This results in a bad block being shown when you switch language/store.

    Example:

    You visit http://domain.com/nl/ and cache the header (It is being cached as /varnish/cache/getBlock/... without the nl up front)

    When you then switch to http://domain.com/fr/ it will still show the cached version of the header that was built in the /nl/ version.

    This can be solved by editing the /Betabrand/Varnish/Model/Observer.php file:

    Line 136:

    $src->setUrl("varnish/cache/getBlock/cachetype/{$src->getCacheType()}/expiry/{$src->getExpiry()}/fingerprint/{$this->_hash()}");
    

    replace by:

    $src->setUrl(Mage::getBaseUrl() . "varnish/cache/getBlock/cachetype/{$src->getCacheType()}/expiry/{$src->getExpiry()}/fingerprint/{$this->_hash()}");
    

    This fix will make it work ;)

    opened by kdckrs 0
  • Mage::registry() persistence for cached blocks

    Mage::registry() persistence for cached blocks

    The extension allows the developer to specify a list of mage::registry() keys (like current_product, current_category, etc.) to be saved in the redis cache when a block has been set as an ESI include.

    The current implementation just serializes the content associated to the specified registry key. The problem is that a lot of Objects are not serializable. For example, the current_product key, containing a Mage_Catalog_Model_Product Object, also contains, inside of the Object, some SimpleXML instances. SimpleXML can't be serialize. In "older" versions of PHP, serializing SimpleXML object doesn't cause too much harm and just raises a Warning, but in more recent versions, an Exception is raised.

    This exception is not currently caught and thus crashes the application.

    Serializing the Mage::registry() keys and put them in cache to make them available between requests is not a good solution. Another more reliable and elegant solution must be found.

    bug enhancement 
    opened by huguesalary 0
  • System Messages Logic

    System Messages Logic

    The logic in Betabrand_Varnish_CacheController::getMessagesAction() handling the caching and displaying of system messages (error messages, success, warning) should be changed. In some cases, the current code fails to display messages when there are some available. Ultimately, the entire logic should be reviewed and changed. This has a pretty high priority.

    bug 
    opened by huguesalary 0
  • ESI Blocks and <default></default> layout handle

    ESI Blocks and layout handle

    When an ESI block is requested, the CacheController.php doesn't load the <default></default> layout handle. The <default /> handle should always be loaded. Will fix that soon.

    bug 
    opened by huguesalary 0
  • Mage::getUrl() bug for ESI blocks

    Mage::getUrl() bug for ESI blocks

    When a block is set as an ESI, a call to Mage::getUrl('*/*/myAction') inside the MyBlock.php file will return varnish/cache/myAction instead of myModule/myController/myAction.

    This is a quite important bug to fix. I will fix it as soon as I can.

    bug 
    opened by huguesalary 0
  • Event triggering cache ban

    Event triggering cache ban

    Create a new parameter in the layout file that allows to specify which event will trigger a cache ban.

    In the current implementation you have to declare your own Event Observers and then write the code that will actually ban the cache. This is a problem as it makes your modules' php code highly coupled with the Varnish module.

    enhancement 
    opened by huguesalary 0
  • Detect when SSL Offloader is used

    Detect when SSL Offloader is used

    In the current implementation, a check with Mage::getRequest()->isSecure() will prevent ESI injections. However, if the installation is behind an SSL proxy, isSecure() will still return true preventing the ESI injection to happen. But in reality, the request is being made on HTTP by the proxy.

    bug enhancement 
    opened by huguesalary 0
  • Magento-Varnish magento extension customised in order to work with Apache Traffic Server

    Magento-Varnish magento extension customised in order to work with Apache Traffic Server

    Hello, is it possible to customise Magento-Varnish extension in order to make it work instead with http://trafficserver.apache.org/ and varnish????

    here are some doc info; http://trafficserver.apache.org/

    http://en.wikipedia.org/wiki/Traffic_Server

    https://github.com/linkedin/atscppapi

    http://daemonkeeper.net/735/apache-trafficserver-the-better-web-cache/ http://fr.slideshare.net/supertom/apache-traffic-server

    https://developer.yahoo.com/blogs/ydnsixblog/open-sourcing-traffic-server-700k-lines-code-9-7861.html

    https://github.com/apache/trafficserver https://github.com/apache/trafficserver/tree/master/plugins/experimental/custom_redirect http://shukitchan.com/blog/2013/01/21/esi-feature-comparison-between-apache-traffic-server-and-varnish/ https://github.com/shukitchan/trafficserver/tree/master/plugins/experimental/esi http://calendar.perfplanet.com/2012/life-on-the-edge-with-esi/ https://www.varnish-cache.org/docs/3.0/tutorial/esi.html#example-esi-remove-and-esi http://opensourcebridge.org/proposals/456 https://www.varnish-cache.org/lists/pipermail/varnish-misc/2009-November/017620.html http://www.mgt-commerce.com/blog/magento-on-steroids-best-practice-for-highest-performance/ http://fr.slideshare.net/thenickberry/reflecting-a-year-after-migrating-to-apache-traffic-server

    Regards, Heather

    opened by topstarnetwork 1
  • Redis does not appear to save keys

    Redis does not appear to save keys

    Running through the debugger and tcp dump, the keys are being sent to redis but unfortunately redis doesn't appear to be storing the keys :(

    Redis working fine for the other CM_RedisSession module.

    Any ideas?

    opened by duffybelfield 0
  • generate pdf invoice 503 error

    generate pdf invoice 503 error

    A bug to fix:When create pdf invoice at magento's backend,it will get 503 error,reference to:https://www.varnish-cache.org/forum/topic/419

    add these code:

    if ( req.url ~ "./admin/sales_order_invoice/print/." ) { set req.http.connection = "close"; return (pipe); }

    to varnnish vcl file vcl_recv will works fine.Thank you for this project,good job!

    opened by ed29 0
  • 404 error from static assets returning with set-cookie

    404 error from static assets returning with set-cookie

    From observation so far; if a static assets (e.g. image) is not available, the VCL will ensure the cookie is removed from the request, but Magento will render a 404, which will include the set-cooke header. The frontend cookie will have a different session id since it was removed from the request.

    The outcome is that the session id changes between requests if there is a 404 response from magento.

    opened by danelowe 0
  • Code Use

    Code Use

    Just wanted to give you a heads up that I've used a lot of your ESI handling code in https://github.com/nexcess/magento-turpentine . Thanks for releasing this under the GPL!

    opened by aheadley 1
  • Refactor code and use HTTP caching headers from HTTP Specs.

    Refactor code and use HTTP caching headers from HTTP Specs.

    Instead of using, for example, a URL path like ".../expiry/3d/..." to determine if an ESI fragment, or a page should be saved in cache, and for how long, use the HTTP headers:

    Cache-Control If-Modified-Since Etags Last-Modified

    enhancement 
    opened by huguesalary 0
Owner
Hugues Alary
Hugues Alary
A Varnish extension for Magento.

Nexcess.net Turpentine Extension for Magento Turpentine is a full page cache extension for Magento that works with Varnish, a very fast caching revers

Nexcess.net 528 Nov 8, 2022
Magento 2 Module that adds Donation Product Type. Enables the customer to add a donation (product) of a preferred amount to the cart.

Magento 2 Module Experius DonationProduct (RC1.0) Demo website: https://donationproduct.experius.nl Magento Marketplace: https://marketplace.magento.c

Experius 23 Apr 1, 2022
Michael Pratt 307 Dec 23, 2022
WooCommerce Empty Cart Button plugin helps you to add Empty Cart button to WooCommerce Pages/Sections using Shortcode only.

WooCommerce Empty Cart Button plugin helps you to add Empty Cart button to WooCommerce Pages/Sections using Shortcode only. How to use? Download the p

Katr 2 Sep 24, 2022
A Magento 1.x module which facilitates automatic purging of static assets from HTTP caches such as browser cache, CDN, Varnish, etc using best practices outlined within the HTML5 boilerplate community.

Magento Cachebuster Cachebuster is a Magento module which facilitates automatic purging of static assets from HTTP caches such as browser cache, CDN,

Gordon Knoppe 129 Apr 1, 2022
Magento extension which makes it impossible for a customer to log in until the account has been activated by the administrator.

This Magento 1 extension is orphaned, unsupported and no longer maintained. If you use it, you are effectively adopting the code for your own project.

Vinai Kopp 120 Oct 10, 2022
Magento 2 custom extension to add custom attributes(longitude, latitude) to customer address

Magento 2 custom extension to add custom attributes(longitude, latitude) to customer address. Then save them to quote model and copy them from quote address to order address on bakend, frontend, rest api

MageArab 2 Jul 14, 2022
Magento2 + Varnish + PHP7 + Redis + SSL (cluster ready)

Docker Magento2: Varnish + PHP7 + Redis + SSL cluster ready docker-compose infrastructure Infrastructure overview Container 1: MariaDB Container 2: Re

Fabrizio Balliano 332 Dec 30, 2022
This extension links MediaWiki to phpBB's user table for authentication, and disallows the creation of new accounts in MediaWiki.

This extension links MediaWiki to phpBB's user table for authentication, and disallows the creation of new accounts in MediaWiki. Users must then log in to the wiki with their phpBB account.

Digitalroot Technologies 22 Feb 8, 2022
Redis-based session handler for Magento with optimistic locking

Cm_RedisSession A Redis-based session handler for Magento with optimistic locking. Features: Falls back to mysql handler if it can't connect to Redis.

Colin Mollenhour 216 Jan 5, 2023
A Redis-based session handler for Magento with optimistic locking.

Cm_RedisSession A Redis-based session handler for Magento with optimistic locking. Features: Falls back to mysql handler if it can't connect to Redis.

Colin Mollenhour 215 Jan 28, 2022
This tool can write the monolog standard log directly to clickhouse in real time via the tcp protocol

log2ck This tool can write the monolog standard log directly to clickhouse in real time via the tcp protocol. If you can write regular rules, other st

Hisune 9 Aug 15, 2022
Rocket Web Prime theme based on Magento Blank that includes our most common customizations.

RW Prime - Magento 2 boilerplate theme RW Prime theme is based on Magento Blank and includes our most common customizations that we make on the majori

Rocket Web FED 37 Aug 8, 2022
A simple implementation of the api-problem specification. Includes PSR-15 support.

ApiProblem This library provides a simple and straightforward implementation of the IETF Problem Details for HTTP APIs, RFC 7807. RFC 7807 is a simple

Larry Garfield 236 Dec 21, 2022
CRUD Build a system to insert student name information, grade the class name, and edit and delete this information

CRUD Build a system to insert student name information, grade the class name, and edit and delete this information

Sajjad 2 Aug 14, 2022
Magento 2 Megamenu extension is an indispensable component, and plays the role of website navigation to help customers easily categorize and find information

Mageno 2 Mega Menu (Magicmenu) helps you create neat and smart navigation menus to display the main categories on your website.

https://magepow.com 35 Dec 1, 2022
Magento 2 Blog Extension is a better blog extension for Magento 2 platform. These include all useful features of Wordpress CMS

Magento 2 Blog extension FREE Magento 2 Better Blog by Mageplaza is integrated right into the Magento backend so you can manage your blog and your e-c

Mageplaza 113 Dec 14, 2022
TYPO3 CMS extension which extends TYPO3 page cache, by tags based on entities used in fluid templates.

Fluid Page Cache for TYPO3 CMS This TYPO3 CMS extension allows you to clear frontend page caches, automatically when a displayed record has been updat

Armin Vieweg 1 Apr 8, 2022
Magento 2 module to quickly acces products, orders and customer from admin menu

Magento 2 module to quickly access product, order or customer views Introduction The Magento 2 backend can be sluggish. Ever wanted to access a produc

null 1 Dec 3, 2021