Whenever I change the configurations e.g. under hst:pages in the CMS console, will it get reflected in the XML files under bootstrap configuration?
On the other hand, when I update the XML file under bootstrap configuration, is it supposed to be reflected in the CMS console as well?
I've tried (I increased the version number in the hippoecm-extension.xml file, cleaned and rebuilt the project) but this doesn't seem to happen
1) Your changes will get reflected in the XML files only if you have the auto-export feature activated. More information on this feature can be found here:
http://www.onehippo.org/library/development/automatic-export-add-on.html
2) You have to do several things for this to work: update the version number in the XML file, mark the item you want to reload as reload on startup, and add the flag -Drepo.bootstrap=true when you start the server. You can find more detailed information on this topic here:
http://www.onehippo.org/library/concepts/update/deploying-content-and-configuration-updates.html
Related
I am going through documentations for project configuration in craftcms not sure what is the different between project-config/write and project-config/modify?
project-config/write takes the config currently stored in the database and writes it out as YAML files in the config/ folder. You usually don't need this since Craft does this automatically whenever you change something in the backend (unless you have turned that off).
project-config/rebuild attempts to rebuild the entire project-config based on the state of the entire database. This is only required in rare edge cases.
Rest you can check the official documentation here:
https://craftcms.com/docs/4.x/project-config.html#what-s-stored-in-project-config
I cannot find an answer to for several weeks. Perhaps my experience in development is not so great :) One site uses the JCH Optimize plugin and I noticed that after clearing the old memory (caches), the CSS and JS file links do not change, i.e. the names of these files remain old. The problem is that the browser checks the file name and if it has not changed, then the site visitors show the old version of the style file. The question itself, where in the plugin (in which code file) i can add some GET parameters ?vers = 1.1 so that for the browser it is a new file and it would update the information for users. I will be glad to hear any solutions. Thanks.
The names of the combined css and javascript files are keyed from the names of the individual files on the page. Clearing the cache will not cause the plugin to generate a different file name.
As of version 7.0.0, there is an option to generate a different cache key if you want to change the names of the combined file. Update your current version to get that capability.
After restoring a semantic media wiki installation from backup the SMW engine does no longer return any query results. I have (re)inserted all regular pages, all form pages, all property pages into the new MW instance. So all content is there but query results remain empty. It seems as the internal data structures maintained by SMW are not filled. How can this be fixed? Are there any specific scripts that need to be run manually?
Indeed the internal SMW cache is not filled after restore. The solution is simple: You need to go to extensions/SemanticMediaWiki/maintenance and run the script rebuildData.php which will reparse every single Wiki page and fill the SMW database accordingly.
Be aware that for this to work your Wiki needs to be configured properly. By default SMW will not process additional namespaces! You need to enable this manually for every single namespace you add yourself in LocalSettings.php after the line where you enable SMW in this file. (This configuration will only have effect if you do this after the line that enables SMW.)
Using ezplatform with "kaliop/ezmigrationbundle": "^3.0".
I read and re-read the manual but cannot see anything about auto-generating yml files from exsiting content types; does anyone have any experience with this and happen to know if/where the docs might live?
We have a list of content types that were created in the backend via the gui and now we need to create migration files for them for better development with the dev team.
Update: This is available on v4+ https://github.com/kaliop-uk/ezmigrationbundle/issues/34#issuecomment-317524072#issuecomment-317524072
This is available on v4+ and answers the question
https://github.com/kaliop-uk/ezmigrationbundle/issues/34#issuecomment-317524072#issuecomment-317524072
I guess that is not how it works!
the bundle generate just an empty yaml file for you and you should fill up the content types (or any other Backend Changes you want) yourself in that yaml file and then take it and apply to your stage or Live Environment.
so unlike Symfony DoctorineMigrationBunlde, this bundle does not read the difference and produce stuff itself.
I have 2 instances of Odoo v9 running in the same server (Ubuntu 14.04). I want to make changes (install modules, change source code or anything) in the developement instance and after confirming they are OK, move the changes to the Production Instance. Is there anyway of doing that without repeating the whole process of development?
Thank you.
As I can understand you do not want to stop the production instance.
If they are only XML files you might be able to get away by only updating the module from the frontend (Apps-> Your Module -> Update. Although if you have modified the __openerp__.py file inside your module you have to enter the debug mode and click Update Apps List first of all.
For changes in files that are inside the static folder of your module, you do not need to stop the server. Although, your users must click ctr + shift + R in order to flush their caches and bring to their browsers the new content.
For Python source code I am afraid that you have to stop both instances of the server so that the code can be correctly recompiled.
(See note 1 on this)
In the end you should stop and update everything because unexpected things might pop up at random times due to resources not been properly updated.
Note 1: The Python documentation about the compilation of Python modules above others mentions:
As an important speed-up of the start-up time for short programs that
use a lot of standard modules, if a file called spam.pyc exists in the
directory where spam.py is found, this is assumed to contain an
already-“byte-compiled” version of the module spam. The modification
time of the version of spam.py used to create spam.pyc is recorded in
spam.pyc, and the .pyc file is ignored if these don’t match.
So theoretically if you modify fileA.py in a module and a new fileA.pyc is generated the server will be able to interpret and use it. In any case I had an issue with two instances running where the py file was creating the field and the XML file was using it and the server reported that a filed had not been created for the XML view, that means that the server did pick up and parse the XML file but did not recompile the py.