We have a problem on a staging system which the same code, same composer.lock, composer install done, cache flushed.
I even activated FroshDevelopmentHelper on Staging and set it to ENV=dev to be able to see more debugging infos.
On Staging:
<!-- BLOCK BEGIN base_body_inner (custom/plugins/OurTheme/src/Resources/views/storefront/base.html.twig) -->
On Local (there the feature works):
<!-- BLOCK BEGIN base_body_inner (vendor/store.shopware.com/moorlfoundation/src/Resources/views/storefront/base.html.twig)
We also ensure a consistent plugin loading order by setting the installed_at, but that is also the same order on both system
The database was also copied from Staging (just base URL changed after the local import) + rebuilt storefront and admin.
Does anybody have a pointer what else could influcence the loading order or cause such a problem?
EDIT:
I added some debug code here:
vi vendor/shopware/core/Framework/Adapter/Twig/NamespaceHierarchy/BundleHierarchyBuilder.php +52
asort($extensions);
dd($extensions); # added
This gives me different results on both systems.
Before Shopware loaded the templates according to installation date - now the TemplatePriority is used, which is in most cases 0, so my theory is, that a kind of chaotic order is constructed, if the TemplatePriority is not set anyhwere.
I am pretty sure, this new feature is the reason:
Since 6.4.13.0 it is possible to set the load order of templates using the template priority. This was a shortcomming for a while and we are very happy about this fix.
Unfortunately it breaks our workflow, where we currently hard-code the plugin installed_at date and assumed that the templates are loaded in a certain way.
Follow up: Set template priority for 3rd party plugins
See also: https://issues.shopware.com/issues/NEXT-23822
Related
Strange enough that I have to ask such a simple question.
I started automating with UFT and I suppose the correct way to check if for instance my login has worked is to add a checkpoint on the next page.
But how do I do that?
All info I get from google is on how to add an already existing checkpoint to may page. But I don't have any.
Here is how I go about automating:
I add manually the relevant objects to the object repository
I create parameters for my action
I create the code that does the steps on the page
one action per page seems to be fine for me
But in the Object Repository of UFT 14.53, there is no button to add a Checkpoint.
A workaround for me would be to just add another Object and check it's existence and forget about checkpoints. Until I hopefully get an answer here, I will try to do just that.
In UFT there are typically two ways to verify that things are working as expected.
Flow (implicit) - In order to verify that progress in the application is successful (e.g. login) one usually just keeps working with the app, assuming that if the previous step failed, the objects needed for the next steps won't exist and the test will fail due to ObjectNotFound errors
State (explicit) - In order to see that objects have a specific state, checkpoints are usually used. Checkpoints are typically added during a record session, I'm not sure if there's a way to add them directly to the repository. An alternative to checkpoints, which works better with keyword driven testing (no recording), is to use the built in CheckProperty method.
I am developing an application in ServiceStack and am trying to sort out deployment on AppHarbor, however for some reason my web.config transforms are not being applied.
I had originally a Web.AppHarbor.config file and changed the Environment Setting to "AppHarbor" - once this failed to work after several updates, I gave up and changed the Environment setting to "Release" and copied the desired transformations into the Web.Release.Config file.
App gets deployed OK but config settings do not reflect the values in the transform file (I verify this by login on with twitter and seeing the callback url for Twitter Auth still tries to redirect me to localhost, which is one of the settings I change in my transform file)
I have also tried the transform tester tool and all works as expected.
Manually publishing the web application to a local folder correctly applies the transformations according to the selected configuration
Does anyone have this working? Is there something obvious I'm missing?
Thanks
It sounds like the Web.Release.config file is not included in the build output. You need to set the Build Action attribute to Content to include it in the build output.
You can confirm whether the file is included in the output by downloading the build from the log page.
I stumbled across this post because I was seeing the same lack of action myself. Upon closer inspection (about 15 times that is) of my Web.Release.config I realized one of the nodes in my config file was not marked xdt:Transform="Replace". Unsurprisingly it did nothing when deployed.
Magento seems to be using "Happy go Lucky" error handling, where all errors in xml files will just cause the xml config file to be ignored. And missing/wrong tags will just be ignored too, sometimes causing Magento to skip parts of the xml file.
But is there any way(A log file or something) which shows exactly what part of the config files Magento skips, and which tags are unknown/wrong. Using Magento 1.6 if that matters.
From what I have seen in Magento, it will throw out the entire XML file if there is invalid XML in it - broken/mismatched tags, erroneous characters, etc. I think it would be somewhat impossible for a xml parser to do any sort of a decent job parsing this out - that's the goal of XML. If my configuration isn't loading, the first think I like to do is go and perform a wellformedness validation on the code, which will show me if I have a problem there.
If there is references to invalid classes, usually it will break. Layout XML is different - it will ignore the block and continue on, which can be a real pain to troubleshoot.
So, to answer your question - no, there isn't a native way to do this. The best way, IMO, is to go and validate it at a third party.
There is logging in Magento, to enable it:
Go into your Admin Panel, then System > Configuration > Advanced > Developer
Under Log Settings ensure Enabled = Yes
This will create two separate logs in magento root/var/log (in my case /var/www/html/var/log)
Exception.log will hold any errors created using Mage::LogException($e)
System.log will hold any logging created using Mage::Log('message')
You can also create your own log files...if you so wish by
Mage::Log('message', null, 'my.log');
This will create a my.log file in the var/log directory.
FYI - I believe the reason Magento handles configuration files in this manner is to protect the rest of the system from an issue with a single extension.
I'm currently editing my portal_normal.vm (server/tomcat/webapps/mytheme-theme/templates) testing if I can write on the file and see it on my browser. I tried putting a test comment "<!-- test -->" just to see if I can really write on the file. So I refreshed the file and hope I can see the comment I've added, but there we're none. So I continued refreshing (ctrl+r),\ and viewing the source code for almost an twenty minutes. After a while when I tried viewing it again it reflected in my source code. So I thought it was cached by either Liferay or my browser.
So I tried tweaking the comment adding version on it ("<!-- test v2 -->"), hoping to see changes. I checked it on another browser and the comment didn't update or include my added version. So I think Liferay is responsible for the issue.
this is what my portal-ext.properties contain:
auth.token.check.enabled=false
# Database settings
jdbc.default.jndi.name=jdbc/LiferayPool
#For removing captch
captcha.check.portal.create_account=false
session.enable.phishing.protection=false
default.regular.theme.id=my_site_WAR_my_theme
#Delete cookies while deleting session
session.enable.persistent.cookies=false
#redirecting null problem.
redirect.url.security.mode=mysite.com
journal.template.velocity.restricted.variables=
admin.email.from.name=Market.Travel Team
admin.email.from.address=admin#mysite.com
# Added because of the Error - No Hibernate Session bound to thread, and configuration does not allow creation of non-transactional one here
hibernate.current_session_context_class=thread
session.enable.url.with.session.id=false
and my portal-developer.properties
theme.css.fast.load=false
theme.images.fast.load=false
javascript.fast.load=true
javascript.log.enabled=true
layout.template.cache.enabled=false
browser.launcher.url=
combo.check.timestamp=true
freemarker.engine.cache.storage=soft:1
freemarker.engine.modification.check.interval=0
openoffice.cache.enabled=false
velocity.engine.resource.manager.cache.enabled=false
com.liferay.portal.servlet.filters.cache.CacheFilter=false
com.liferay.portal.servlet.filters.themepreview.ThemePreviewFilter=true
Addition: When I tried editing the css files I can see the changes fast. Just one reload the the changes appear. I think it is just in my velocity template that take some time or there's something wrong.
Liferay version: Liferay Portal Community Edition 6.0.6 CE
Thank You!
There is really no need to define your own portal-developer.properties. By adding -Dexternal-properties=portal-developer.properties to your JAVA_OPTS in tomcat/bin/setenv.(sh|bat) Liferay will use it's default developer settings, which are almost identical to what you have provided. However, I do not believe this is contributes to (or could resolve) your problem. More details here.
The developer properties do allow you to make live changes to the templates provided you are changing the right file. Due to the default context.xml Liferay provides to the deployed webapps, the webapps are copied/cached in tomcat/temp/{id}-webapp-name. This means if you change the template in webapp/mytheme then it may take tomcat a while to pick up on the change, if it notices the change at all (this will depend on the tomcat configuration). On the other hand, if you make a change in temp/1-mytheme it will show up immediately. Editing the files in the temp folder is probably not ideal, so...
How to fix this: (no specific order)
Prevent Tomcat from using the temp directory for your theme. Create a context.xml file for your theme.
<Context cachingAllowed="false"/>
This file should be placed in the META-INF folder of your
theme. If you are using the Liferay auto-deploy feature the
context.xml file may be clobbered, here, and here. If this
is the case you will need to find a work around that best suits your
needs, such as modifying the context.xml after the theme is deployed.
If you are using the Liferay Plugin-SDK the you can follow the fast plugin development guide for setting up your development environment.
I have a Managed Object Context to which I add two different SQLite stores. I use Configurations in the Mananged Object Model to assign certain entities to one store and other entities to the other. The Configurations are called "UserDB" and "MainDB".
Everything works okay until I try to use automatic migration. After creating a new Managed Object Model version, and adding a new attribute to one of the entities in the UserDB Configuration, I get an exception when adding the old version store (for the UserDB related store) to the store coordinator: 'Model does not contain configuration 'UserDB'.' I can find no hits for this error on Google. Anyone out there using multiple stores with Configurations? Anyone have an idea what I might be doing wrong?
The stack looks like this:
objc_exception_throw
-[NSManagedObjectModel isConfiguration:compatibleWithStoreMetadata:]
-[NSStoreMigrationPolicy sourceModelForStoreAtURL:metadata:error:]
-[NSStoreMigrationPolicy(InternalMethods) _gatherDataAndPerformMigration:]
-[NSPersistentStoreCoordinator addPersistentStoreWithType:configuration:URL:options:error:]
-[MyAppDelegate persistentStoreCoordinator]
This looks like a bug with migration+configurations. I was able to work around the problem by going through the same motions and passing nil for configuration when calling addPersistentStoreWithType. The migration happens, and then I can make a new persistent store coordinator and add the stores again with the proper Configuration string arguments.
This is the second configuration related bug I've run into. Not a well tested feature apparently.
I had the same problem. The fact pattern was identical and the error message the same. It turned out, however, to be the result of my own mistake.
Let's say the old model was Blah.xcdatamodel and the new Blah 2.xcdatamodel. I had started making changes to Blah before realising my mistake and creating Blah 2. I then used my version control system (Git) to revert to the old Blah and then recreated Blah 2. Everything looked right. But I must have done something wrong in the reversion process, because when I thought to double check that Blah.xcdatamodel in my current project folder was really the same as Blah.xcdatamodel in the project folder I used to build the previous version of the app (fortunately I always keep a zipped archive of the project folder for each released version as I don't fully trust version control systems), I found that they were in fact different, albeit that they looked identical in XCode. The file size was different, for instance.
I substituted the old Blah into my current project folder, and lo and behold it all went perfectly, without any need for the workaround described by Ken.
I am not saying that Ken had necessarily made a similar mistake, but if you do encounter this message it is at least worth confirming that the model you are migrating from is REALLY the model that was used to create the data in question.