This is the scenario (CQ5.6). Let's say there is the following node /content/geometrixx/articles, with articles inside of it. In author instance I create a package as a backup of that node. Then I deactivate article1 inside of articles, if I try to access the page I get a 404 page, that is fine. However if I build the backup package again and then replicate it, the deactivated page (article1) is available, that is, I do not get the 404 but instead the article.
Is there a way to replicate a package while preserving deactivated pages? That is, how I avoid re-activation?
Replicating package means that you are replicating every thing available in Package. Which means publish environment will have deactivated pages also. There are several ways to handle it, like:
Simplest way is to add a check in template (as first rule) to see if Env==publish && requested resource ==not activated, if so, return 404 page.
Another way is to create a script to delete all deactivated pages, and run this script on publish after page activation.
Add exclude filters in your package to exclude such pages.
I would recommend to use #1 as this is one time change and will be future proof.
should use treeactivation: http://localhost:4502/etc/replication/treeactivation.html, much safer (since you have 3 options: Only Modified, Only Activated and Ignore Deactivated)
Related
I'd like to configure the Adobe Cloud Manager production pipeline to invalidate the whole dispatcher cache. What paths do I have to give at the production pipeline dispatcher invalidation configuration to have that done? Is it possible to give a pattern here that matches everything? The page-invalidate description talks about a path-pattern, but doesn't describe what exactly that means.
We work with statfilelevel=2. It seems the .stat files are very important for that, though the description given here is unfortunately not precise enough, not sure I understand that right.
I tried to configure /content as path - that just touches /mnt/var/www/html/.stat (/mnt/var/www/html is the docroot), which seems to apply to nodes like /* but not like /content/* .
If I give /content/oursite, that touches /mnt/var/www/html/content/.stat , too, but that does seem to apply to nodes like /content/oursite or /content/othersite, but not to pages like /content/oursite/about - for which would /mnt/var/www/html/content/oursite/.stat be relevant, if I understand that right.
Do I seriously have to enumerate a page in each site that has a .stat file, or is there a more sensible way to get everything invalidated? After all, a deployment could easily change the HTML of every page if a component has changed.
If you have ACS commons installed then you can try to use this powerful feature
https://adobe-consulting-services.github.io/acs-aem-commons/features/dispatcher-flush-rules/index.html
I need some help, I'm starting with this automation stuff, I like it but I'm still learning, recently I create a test case that basically is, going to a certain page and click on a button to upgrade the account on an specific sale, so I did that but when I got my PR reviewed and devops ask me if I can add an assertion.
So, this code is on the spec file not on the page objects file, so the devops mean I have to create the code on the page object file and then call it on the spec file???? any tip would be great and thanks!
You can do it either way. You can write the assertion in the spec file, or write the assertion in the page objects file and call it from the specs file. If the latter is your framework's code convention, you may want to do it that way for consistency, but either way should work.
I am currently working on with a solution that would be able to clone/copy/backup my existing rep:policy. 'Cause when we do some jobs it accidentally removed. I am trying to apply this kind of fix, but am failing to. It says it is an invalid path.
javax.jcr.security.AccessControlException: OakAccessControl0006: Isolated policy node. Parent is not of type [rep:AccessControllable]
final Workspace ws = session.getWorkspace();
ws.copy("/etc/commerce/products/abccompany/TvPackChannelMap/rep:policy","/tmp/nxt/TvPackChannelMap/rep:policy");
Are there other ways that I can be able to take the rep:policy thru code?
You need to make sure that your job does not touch the permissions or the rep:policy, this is the best way forward for you.
The exception could be because of /etc/commerce/products/abccompany/TvPackChannelMap/rep:policy does not exist or the user whose session you are using does not have read access to the node.
Make sure the path is correct, copy paste it to your CRX/DE to make sure it exists.
I have tried to use your code to copy a rep:policy from one node to another, works fine. But I would not* recommend copying permissions that way. The best practice is to use the Access Control Management API for all things permissions.
You can check, install and use the access control tool from netcentric. It offers a jmx interface for exporting AC entries and maybe also some APIs you could use to implement your custom solution.
The Other approach is to retrieve the ACL permissions through the query language.
For example, SELECT * FROM [rep:ACL] or SELECT * FROM [rep:ACE] where [rep:principalName] is not null should give you the results.
For more information, I would recommend you to check the ACS commons ACL Packager Implementation which is available on GitHub.
Reference Link - https://github.com/Adobe-Consulting-Services/acs-aem-commons/blob/master/bundle/src/main/java/com/adobe/acs/commons/packaging/impl/ACLPackagerServletImpl.java
Sometime someone want to change inside something crx directly on environment.
Often it is a cause of unworking state of environment. And often enough hard to find the cause of the problem. And I think it is will be helpful if cq5 crx will have audit log. something like this.
12.12.12 21:03 /etc/blueprints/geometrixx was removed [rollout]
...
maybe CQ5 has something like this already?
Assuming these changes to the repositories are made using crxde lite[/crx/de/index.jsp] or content explorer [/crx/explorer/browser/index.jsp] , there is an indirect way to find out who did it.
The data can be fetched by looking into two different logs request.log and audit.log [these files can be found at \crx-quickstart\logs folder ]
The modifications to nodes are POST requests. These are logged in request.log , the path of the request will only show the interface used or to root node. If you search the time stamp of the POST in audit.log you can find which user did a GET request.
This is not direct way, nor will it tell more of the changes except for which user read the node at the time of the POST .
I've been playing around with Typo3 Neos. So I've installed it according to this tutorial, except i didnt import the demo Package.
Just to be safe, I deactivated and deleted the TYPO3.NeosDemoTypo3Org package, before flushing the cache. So when i log into the backend, there is the "print" button, in the preview part of the menu, and there are custom nodes which are defined in the demo package (which i deactivated and deleted). It isnt hard to imagine, when i try to add these Nodes i receive an error message:
Failed to render element
page<TYPO3.Neos:Page>/
body<TYPO3.TypoScript:Template>/
content/
main<TYPO3.Neos:PrimaryContent>/
default<TYPO3.TypoScript:Matcher>/
element<TYPO3.Neos:ContentCollection>/
itemRenderer<TYPO3.Neos:ContentCase>/
default<TYPO3.TypoScript:Matcher>/
element<TYPO3.NeosDemoTypo3Org:Carousel>
Invalid resource URI "resource://TYPO3.NeosDemoTypo3Org/Private/Templates/NodeTypes/Carousel.html": Package "TYPO3.NeosDemoTypo3Org" is not available. (201402131504259fdc08)
It clearly says there is no Carousel Node (because the package where the carousel should be, was deleted). So here is my Question: Why is this still there?
Make sure you flushed the Cache correctly. In Production context it is
FLOW_CONTEXT=Production ./flow flow:cache:flush --force
But it seems more likely that in your TYPO3 Content Repository, you still have a Carousel content which of course isn't deleted on installing the Demo Package. So have a look at your Node table and check for the node type TYPO3.NeosDemoTypo3Org:Carousel and delete these nodes.