CODEWITHSUNDEEP
gitsecuritymagentopatch
Jared
Jared

Reputation: 245

Magento's SUPEE-6788 patch not working with Git/Github

After I successfully installed the SUPEE-6788 patch on my localhost and pushed the changes to development, I noticed a handful of issues in my dev environment that I did not see on my Localhost.

The first issue I found was that none of my contact form blocks were appearing.

Then I noticed that it wasn't limited to the contact form, it was anywhere that had a form in it (via CMS page).

After digging a bit deeper (exception stack trace), I found out that I was missing a table that didn't exist before called 'permission_block'.

After a bit more digging, I found out that there were many database updates that occurred in the patch which did not run when pushed to development (via upgrade script). Looking at the patch directly, I can see that the upgrade scripts were in fact updated, and that the config files reflected those updates (version number and all). But for some reason, they did not run.

Now I'm left with a bit of a dilemma. I'm not sure what updates happened and what updates have not (in the development environment).

Are the SUPEE patches Magento releases not meant to be used in conjunction with Git/Github?

Do I need to apply the patch individually to each build instead of pushing the build after patching?

Upvotes: 3

Views: 637

Answers (1)

Alana Storm
Alana Storm

Reputation: 166066

Are the SUPEE patches Magento releases not meant to be used in conjunction with Git/Github

There's nothing in the SUPEE patches that would prevent you from using Git/GitHub to manage your repository.

That said -- your question doesn't quite make sense, and I think it may be due to a misunderstanding on how those database upgrades are applied.

Magento Setup Resource scripts allow a module developer to update the database. Whenever Magento loads an uncached HTTP request, it will

  1. Examine the version of all declared modules in app/etc/(code|community|local)

  2. Compare that version to the version stored in the core_resource table

  3. If a more recent version is installed on the file system, run the appropriate setup resource scripts in sql/ folder

  4. Update core_resource to indicate the version installed

Based on your question, it sounds like one of the following happened

  1. You uploaded the updated files from source, but never cleared cache in production, and the setup resource scripts never ran

  2. You uploaded the updated files, did clear the cache, but something about your production system prevented the scripts from fully running. Since MySQL doesn't have transactional updates for all structure changing commands, it's possible for a setup resource script to not fully run, but still update the core_resource table with the same version.

I'd start by comparing the extension version in core_resource with the versions on the file system (in config.xml)

Also, you can use the sys:setup:incremental command that's a part of the n98-magerun program to manually apply updates without clearing the cache. This can also help you diagnose which, if any, failures might be causing problems.

Finally, since you have a working development version, as a last resort you can use mysqldump to dump the structure of each database, and then compare with a visual diff tool (like WinMerge) to determine what tables/rows are missing. You'll need to apply a bit of intelligence to this (since dev might also have other un-needed things)

Upvotes: 4

Related Questions