I have been building a module and making numerous changes without any problems until just now:
I removed a configuration variable from my extension's system.xml file but the field is still in the config. I disabled all caching, flushed all caches (both through magento admin and by manually deleting everything in the directories) but it STILL won't go away.
As a test, I added it back to the system.xml file using the same node name but changing the label and it picked up the change. I was also able to hide it by setting <show_in_...> to 0. However, after it went away, I removed it from the system.xml file and it showed up again in the admin. I have to imagine this is a caching issue but I can't figure out what to flush to make it go away.
Any thoughts?
Two things to check. When you save a configuration value, magento (currently) persists it to the core_config_data table. Even if you remove the configuration field from your system.xml config. that path/value pair will still be stores in this database. Do a
SELECT * FROM core_config_data WHERE path = '/foo/baz/bar'
To see if there's still a values in there. If it is, calls to Mage::getStoreConfig will still return a value, again regardless of what's in system.xml
Secondly, Magento allows you to stores a default value for each configuration path in config.xml. Look under the
<default>
<foo>
<baz>
<bar>1</bar>
</baz>
</foo>
</default>
node for a nested tree path that matches your configuration path. If this node is present then this value will be returned for requests to Mage::getStoreConfig.
system.xml values are stored in the db, core_config_data: have you delete it there?
Related
In Acumatica v22R1, I'm trying to copy an existing screen (Business Accounts), give it a new screen ID and name, and modify it. After doing this, and changing the references in the .ASPX and code-behind to match the new screen ID, I add it to a customization project and try to publish it. The errors I get are related to an invalid path it's looking for in the .ASPX looking for *.inc files. For example:
<!--#include file="~\Pages\CR\Includes\ContactDetails.inc"-->
First thing I try is to just remove this line from the .ASPX. When I publish, Acumatica puts this line back in and it fails again. The error is looking for files in a different path --
C:\Program Files\Acumatica ERP\Customization\<instance>\<instance>Validation\<instance>Website\Pages\AK
This path is apparently generated during publishing. The "AK" on the end is the screen id prefix we use for custom screens. After the validation errors are thrown, I look in this location, and indeed the files it's looking for aren't there. I also tried to copy them there manually from the CR path, but of course they get wiped out automatically when Acumatica publishes and regenerates these folders.
Any ideas what I can do to resolve or get around these errors?
I was able to resolve this by copying all of the referenced *.inc files from the CR pages folder to my custom AK pages folder, then include them in the customization project. And also modify the .ASPX to change the path of these .inc files to my custom folder. The publish then leaves it alone and I can now build without error.
I've successfully imported a *.bprelease file to my Blue Prism environment, but the contents are not visible in processes list.
What can I/should I do to have the contents of the package appear in the list after importing?
This problem lies in a bug in new version of Blue Prism. It is actually quite common, I've seen this happen for a few people in my team. There are two things needed to know to fully understand the problem:
Since 6.3 (the multi-team env. upgrade) when you import an object/process that is not in a group, it will be added to a new group called 'Default'
Blue Prism will not allow you to manually add a group with the name of an existing group (under the same parent group)
If a group with a duplicate name gets created anyway (by an import or by DB command), one of the groups will not be displayed
And that is what happened here.
The easiest thing to resolve this problem is to simply rename the 'Default' folder you see to something else and then refresh the view (hit F5). You should see a new folder pop-up, with your invisible objects.
Alternatively, you could achieve the same results with a couple of SQL scripts, but this is much quicker.
Sometimes even renaming the default folder does not work.
It is because there is a previous object (for example) with the same name, but not assigned to any folder.
We have solved the issue importing the object alone, and chosing "renaming the previous version" option instead of overwriting. So, the object is properly imported and placed in the Default folder, from where you can move it to the right one
While installing application i want to prevent overwriting my DB file if it already exists at specified location.
As i am new to using installshield could any please guide.
Tried setting Never Overwrite property of component to true but didn't work in my case, it's still overwriting my DB file.
There is a possibility that Always overwrite property is set to checked on file level, you can check that by right clicking on db file under component and then click on property menu.
If it turns out to be checked then set it to unchecked.
How can I store elasticsearch settings+mappings in one file (like schema.xml for Solr)? Currently, when I want to make a change to my mapping, I have to delete my index settings and start again. Am I missing something?
I don't have a large data set as of now. But in preparation for a large amount of data that will be indexed, I'd like to be able to modify the settings and some how reindex without starting completely fresh each time. Is this possible and if so, how?
These are really multiple questions disguised as one. Nevertheless:
How can I store elasticsearch settings+mappings in one file (like schema.xml for Solr)?
First, note, that you don't have to specify mapping for lots of types, such as dates, integers, or even strings (when the default analyzer is OK for you).
You can store settings and mappings in various ways, in ElasticSearch < 1.7:
In the main elasticsearch.yml file
In an index template file
In a separate file with mappings
Currently, when I want to make a change to my mapping, I have to delete my index settings and start again. Am I missing something?
You have to re-index data, when you change mapping for an existing field. Once your documents are indexed, the engine needs to reindex them, to use the new mapping.
Note, that you can update index settings, in specific cases, such as number_of_replicas, "on the fly".
I'd like to be able to modify the settings and some how reindex without starting completely fresh each time. Is this possible and if so, how?
As said: you must reindex your documents, if you want to use a completely new mapping for them.
If you are adding, not changing mapping, you can update mappings, and new documents will pick it up when being indexed.
Since Elasticsearch 2.0:
It is no longer possible to specify mappings in files in the config directory.
Find the documentation link here.
It's also not possible anymore to store index templates within the config location (path.conf) under the templates directory.
The path.conf (/etc/default/elasticsearch by default on Ubuntu) stores now only environment variables including heap size, file descriptors.
You need to create your templates with curl.
If you are really desperate, you could create your indexes and then backup your data directory and then use this one as your "template" for new Elasticsearch clusters.
So I'm new to XUL.
As a language it seems easy enough and I'm already pretty handy at javascript, but the thing I can't wrap my mind around is the way you access resources from manifest files or from xul files. So I did the 'Getting started with XULRunner' tutorial... https://developer.mozilla.org/en/getting_started_with_xulrunner
and I'm more confused than ever... so I'm hoping someone can set me straight.
Here is why... (you may want to open the tutorial for this).
The manifest file, the prefs.js and the xul file all refer to a package called 'myapp', that if everything I've read thus far on MDN can be trusted means that inside the chrome directory there must be either a jar file or directory called myapp, but there is neither. The root directory of the whole app is called myapp, but I called mine something completely different and it still worked.
When I placed the content folder, inside another folder called 'foo', and changed all references to 'myapp' to 'foo', thus I thought creating a 'foo' package, a popup informed me that it couldn't find 'chrome://foo/content/main.xul', though that's exactly where it was.
Also in the xul file it links to a stylesheet inside 'chrome://global/skin/' which doesn't exist. Yet something is overriding any inline styling I try to do to the button. And when I create a css file and point the url to it, the program doesn't even run.
Can someone please explain what strange magic is going on here... I'm very confused.
When you register a content folder in a chrome.manifest you must use the following format:
content packagename uri/to/files/ [flags]
The uri/to/files/ may be absolute or relative to the location of the manifest. That is, it doesn't matter what the name of the containing folder is relative to your package name; the point is to tell chrome how to resolve URIs of the following form:
chrome://packagename/content/...
The packagename simply creates a mapping to the location of the files on disk (wherever that may be).
The chrome protocol defines a logical package structure, it simply maps one URL to another. The structure on disk might be entirely different and the files might not even be located on disk. When the protocol handler encounters an address like chrome://foo/content/main.xul it checks: "Do we have a manifest entry somewhere that defines the content mapping for package foo?" And if it then finds content foobar file:///something/ - it doesn't care whether that URL refers to a file, it simply resolves main.xul relatively to file:///something/ which results in file:///something/main.xul. So file:///something/browser.xul will be the URL from which the data will be read in the end - but you could also map a chrome package to another chrome URL, a jar URL or something else (theoretically you could even use http but that is forbidden for security reasons).
If you look into the Firefox/XULRunner directory you will see another chrome.manifest there (in Firefox 4/5 it is located inside omni.jar file). That's where the mappings for global package are defined for example.