When I change the profile version for an add-on that I wrote I always get the message above.
This add-on has been upgraded. Old profile version was 10. New
profile version is 11. There is no upgrade procedure defined for
this add-on. Please consult the add-on documentation for upgrade
information, or contact the add-on author.
So how I can define a procedure to upgrade an add-one?
in your configure.zcml (or preferably in a separated upgrades.zcml included in configure.zcml), you need to declare your upgrade step like that:
<genericsetup:upgradeStep
source="22"
destination="23"
title="Remove such js from registry"
description=""
profile="Products.MyProduct:default"
handler=".upgrades.upgrade_22_to_23"
/>
and you need a upgrades.py file to implement the upgrade step (just an example):
from Products.CMFCore.utils import getToolByName
def upgrade_22_to_23(context):
js_id = '++resource++blabla/blibli.js'
jsregistry = getToolByName(context, 'portal_javascripts')
jsregistry.unregisterResource(js_id)
Note: in zcml, source might be set to '*' if you want the step to apply from any previous profile version to the one you target.
Related
I've installed D9 plus devel and created a custom theme (with all the necessary files, works nicely) and enabled all the necessary dev-centric settings, but it seems that the necessary functions like dd() or drupal_dump() are not found. I've already checked that everything related to the devel module (devel, devel generate, devel web profiler) is enabled in my Drupal.
Any help appreciated!
drupal_dump(), alias dd(), is not provided by devel, but by another module named twig_tweak. It requires Symfony's VarDumper component to work. You can install them using composer :
composer require --dev symfony/var-dumper
composer require drupal/twig_tweak
drush en twig_tweak
ddm() doesn't print anything to the screen but outputs a variable to a file named drupal_debug.txt in the site's temp directory.
More on devel functions here.
Long story
In drupal 7.x and up to version 8.6.0, dd() was indeed provided by the devel module, but it was an alias for drupal_debug() (d7) and DevelDumperManager::debug() (d8), but it has been deprecated and replaced by ddm() since 8.6.0, because Symfony's VarDumper component already has a function named dd().
Now to add further confusion, twig_tweak is using the alias dd() for drupal_dump() (source).
Even if both functions end up calling Symfony's VarDumper::dump(), Symfony's dd means "dump and die" and is meant to immediately ends the execution of the script after dumping the variables, whereas twig_tweak's drupal_dump/dd does not.
The exact same thing happens in Laravel : it uses Symfony's VarDumper and overrides its dd function with a function that doesn't behave the same, instead of using a different name.
As part of installation of a WPF application using .NET 6 and a WiX installer, I would like to check whether the .NET 6 runtime is installed.
WiX provides pre-defined properties to check this for .NET framework but nothing for .NET Core and beyond so I am attempting to check for the presence of a registry key.
There is a registry key that can be checked under: HKEY_LOCAL_MACHINE\SOFTWARE\dotnet\Setup\InstalledVersions\x64\sharedhost\Version
However, if I uninstall the runtime the registry key does not get removed, is there any other reliable way to check whether the runtime is installed, as well as which version is installed?
WiX 3 currently doesn't handle this natively. It is being worked on for WiX v4 (GitHub issue). Reading the issue led me to these tools as a current workaround.
https://www.nuget.org/packages/Microsoft.NET.Tools.NETCoreCheck.x86
https://www.nuget.org/packages/Microsoft.NET.Tools.NETCoreCheck.x64
You can use the files inside of these packages to check for a runtime. Either by running NetCoreCheck.exe directly or using the custom action DLL provided.
NetCoreCheck.exe -h to see help. But you'll want something like this:
netcorecheck --runtimename Microsoft.NetCore.App --runtimeversion 6.0.0
I don't know how to use the custom action dll but I do see it has two DLL exports.
ordinal hint RVA name
1 0 00001500 CheckNETRuntime
2 1 00002260 get_hostfxr_path
You may use the Custom Action DLL mentioned in Hank's answer if you want to integrate this in your WiX project.
You can use the NuGet package to obtain the dll.
Unfortunately there seems to be no documentation in existence for this DLL, so I used the source code to figure out how this works.
First you need to define a few properties that are used as input parameters for the .NET runtime check, and for the result of the check.
<Property Id="CheckNETRuntime_Framework" Value="Microsoft.AspNetCore.App" />
<Property Id="CheckNETRuntime_Version" Value="6.0.0" />
<Property Id="CheckNETRuntime_Result" />
CheckNETRuntime_Framework is the framework to search for. There are currently 3 options:
Microsoft.NETCore.App
Microsoft.AspNetCore.App
Microsoft.WindowsDesktop.App
CheckNETRuntime_Version is the version of .NET to look for.
The result will be stored in CheckNETRuntime_Result. A value of 0 indicates the runtime was found, any other value indicates it was not found.
To run the custom action, do this:
<Binary Id="CustomActions" SourceFile="NetCoreCheckCA.dll" /> <!-- This should be the path to the dll -->
<CustomAction Id="CheckRuntime" Return="ignore" BinaryKey="CustomActions" DllEntry="CheckNETRuntime" />
<InstallExecuteSequence>
<Custom Action="CheckRuntime" Before="LaunchConditions" />
</InstallExecuteSequence>
<InstallUISequence>
<Custom Action="CheckRuntime" Before="LaunchConditions" />
</InstallUISequence>
Note: you need to add Return="ignore" if you do not want the installer to fail when the runtime was not found (as the return value if not 0, which indicates a failure).
The CheckNETRuntime_Result property can be used elsewhere in your setup, for example you could use it in a condition:
<Condition Message=".NET 6 runtime is not installed">
<![CDATA[CheckNETRuntime_Result=0]]>
</Condition>
There has been an error processing your request
Please upgrade your database: Run "bin/magento setup:upgrade" from the Magento root directory.
The following modules are outdated:
Magento_CustomWidget schema: current version - none, required version - 2.0.0
Magento_CustomWidget data: current version - none, required version - 2.0.0
Error log record number: 1078485663282
my code is module.xml
<?xml version="1.0"?>
`<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"` xsi:noNamespaceSchemaLocation="urn:magento:framework:Module/etc/module.xsd">
<module name="Magento_CustomWidget" setup_version="2.0.0"/>
</config>
I had the similar issue and it's likely to be caused by renaming your module(ie: when you try to make a backup copy and leave it in the same directory, ideally we should first disable the module then make a copy), and you must have run bin/magento setup:upgrade - not knowing that you're registering two identical module into database.
How I did to fix the issue was to go to database table: setup_module and find the entry in your case is: Magento_CustomWidget, then update the schema and data both to 2.0.0. It's an easy fix if you have phpmyadmin, see if it helps.
I have a Plone site with a traditional product BaseProduct (versioned directly in the Products filesystem directory of the Zope installation); the rest of the setup is buildout-based.
For a fork of the project, I need another product AdditionalProduct, which I made the same way (I know it's not the current state-of-the art method; but that's how it worked before for me ...).
Now I was able to install AdditionalProduct using the quickinstaller (for now it contains a single skin directory with a single template only, but this will change, of course).
Sadly, this ceased to work; the product is not shown in the quickinstaller anymore. There is no visible error; I was able to pdb.set_trace() it during instance startup, and there is no error in the error.log either.
The profiles.zcml file looks like this:
<configure
xmlns="http://namespaces.zope.org/zope"
xmlns:genericsetup="http://namespaces.zope.org/genericsetup"
i18n_domain="BaseProduct">
<include package="Products.GenericSetup" file="meta.zcml" />
<genericsetup:registerProfile
name="default"
title="AdditionalProduct"
directory="profiles/default"
description="Extension profile for AdditionalProduct."
provides="Products.GenericSetup.interfaces.EXTENSION"
/>
</configure>
(Copied and changed from an earlier AdditionalProduct of another fork; I don't really understand that "meta.zcml" part.)
How can I debug this?
I'd be willing to "eggify" my product (AdditionalProduct first, since it has the problem; perhaps BaseProduct later as well), but I'm not sure about the amount of work, and a How-To would be useful ...
Your product should have a configure.zcml file that includes your profiles.zcml with the following directive:
<include file="profiles.zcml" />
Is it the case ?
You can debug this by ruling out the following:
The ZCML is not loaded (introduce a syntax error in profiles.zcml and
restart Plone to ensure profiles.zcml is loaded.)
You don't have the 'z3c.autoinclude.plugin': 'target = plone' entry point (not applicable as you are not using a Python package)
Your product is not loaded by Zope2 because it's not in the products folder, or has some related issue e.g. missing __init__.py.
Also you may not need the following, as it should already be included by Plone before your products is loaded:
<include package="Products.GenericSetup" file="meta.zcml" />
(And file='meta.zcml' means "load meta.zcml instead of the default file name i.e. configure.zcml")
Lastly, I'd recommend creating a Python package (AKA "eggify"). See the following for an overview:
http://blog.aclark.net/2015/06/01/plone-add-on-development-for-command-line-savvy-developers/
I'd like to install liip/imagine-bundle in my symfony 2 project. But in order to make barcodes, I installed previously MopaBarcodeBundle.
MopaBarcodeBundle requires "avalanche123/imagine-bundle" which requires imagine/imagine: v0.4.1
And
LiipImagineBundle requires imagine/imagine: ~0.5,<0.7
Obviously composer detects the conflict, as he cannot unistall v0.4.1, and that version is not enough for LiipImagine.
I'd like to know how I could bypass this. Create sorts of aliases in composer and keep the two versions on my project ? I'm not a pro in version management, so I guess this is not possible.
Thank you very much for any help.
Ok, after some code inspection i figured out a way around. MopaBarcodeBundle doesn't really requires avalanche123/imagine-bundle, but it uses it in the service declaration. (To make the link with Imagine classes).
So I changed the service.xml file containing the BarcodeService declaration.
<parameter key="imagine.gd.class">Imagine\Gd\Imagine</parameter>
<service id="imagine" alias="imagine.gd" />
<service id="imagine.gd" class="%imagine.gd.class%" />
I guess thoses lines could be factorised, but i chose to keep it as it was done in avalanche123.
Also a constant from avalanche was used in 5th argument, I changed it to :
<argument>%kernel.root_dir%../web</argument>
Finally I removed avalanche, and then install a newer version of imagine/imagine