I installed two instances of magnolia and converted one of them to public to receive publishing from the first instance.
I followed the hello-magnolia tutorial (from this link on the official site), created the template on the author instances and the page was created and previewd successfully. However, when it is published it appears on the public instance as unknown-template and generates an error. I copied the hello-magnolia module from the modules directory on the author instance to the public instance and the problem was solved.
When I followed the same tutorial but on a downloaded bundle, I did it not copy the template manually and it was published successfully.
Why do I have to copy the templates manually from author to public now and how I can have the same behaviour like the downloaded bundle?
Since you don't link the tutorial you are referring to, one can only guess.
Quoting from one I've found "Magnolia continuously scans the file system folder defined by the magnolia.resources.dir property." Most likely reason for both author and public instance seeing templates instantly in case of tutorial is that both instances have the above mentioned property set to point to same directory.
In case of separate instances in your latter installation, this is most likely not the case. To change it (assuming both instances are running on same VM or share a network drive) you need to point them both to the same directory. The property magnolia.resource.dir can be set in magnolia.properties file located in the webapp representing each instance under WEB-INF/config/default/magnolia.properties.
That said, it is not necessarily best practice to point both instances to point to same version of files. If you do so, you might be limiting yourself in some scenarios. Say you are preparing some campaign or new version of the web and want to have new templates already available in author for editors while on public you want to maintain current view ... if both point to same folder you can't do so. OTOH maintenance is simpler and there's no errors caused by forgetting to update templates in each of the instances ... just saying so you know how the choices you make affect what you might be able to do in the future.
Related
I need to create a backup service so I intend to save the SQLite database file on each platform. The saved file should be available after the uninstall of the app.
I intend to use the Downloads folder (which should be available on every platform).
I have created an interface and use the following code per platform:
Interface:
public interface IBackupService
{
string GetDownloadPath();
}
Android:
public string GetDownloadPath()
{
return Android.OS.Environment.DirectoryDownloads;
}
UWP:
public string GetDownloadPath()
{
return Windows.Storage.KnownFolders.???????;
}
What should I do about that? Is there a public library that I could use?
There does not seem to be a general downloads folder as per this documentation on KnownFolders. So your assumption on the Downloads folder being on every platform doesn't seem to be correct.
If we dive in a bit further we get to the DocumentsLibrary which seems the obvious choice for this kind of purpose, but it is not. Microsoft says:
The Documents library is not intended for general use. For more info,
see App capability declarations. Also, see the following blog post.
Dealing with Documents: How (not) to use the documentsLibrary capability in Windows Store apps
The paragraph after that seems to describe what we have to do then;
If your app has to create and update files that only your app uses,
consider using the app's local folder. Get the app's local folder from
the Windows.Storage.ApplicationData.Current.LocalFolder property.
So, as I can extract from your question you only want to use storage for your app, so the Windows.Storage.ApplicationData.Current.LocalFolder seems to be the right choice according to Microsoft.
Is it possible to have both Magnolia Public and Author under 1 instance in Jelastic? If so, how?
According to your request, I'm glad to inform you that you can easily deploy Magnolia Public and Magnolia Author under 1 instance.
As a first step, you should deploy the primary Magnolia application, you can find out that it's can be done in-one-click with help of the appropriate Magnolia CMS widget at our Marketplace
in the Portal/CMS section.
You can manage your applications and files there using Jelastic dashboard, FTP, WebDav or SSH access. In your case there is necessary to establish the SSH Access to the Tomcat instance
and perform the following:
cd /opt/tomcat/webapps/ && cp ROOT.war ROOT2.war
After the copying was finished restart the Tomcat instance.
Having reached this goal, you will obtain two separate Magnolia CMS applications.
Installed files are located at webapps directory which after the mentioned above actions will have two contexts
According to the official Magnolia documentation, it will be necessary to provide the changes in corresponding configuration files
also, it should be mentioned that the copied Magnolia application will have the same settings as an original context ROOT
so before the performing the required changes you should create another DB at your MySQL instance and then specify it for using of the second/copied application.
As a result, you will have two independent Magnolia application one of which could be set Public mode and another one to Author.
I have an Alfresco module that I would like to have do some cleanup when a new version of it is installed.
In the current situation, an older version of the module created a folder node with custom properties at the root of the repository. We've since decided to have multiple such nodes, and none of them at that location. I'd like to put into the next version of the module code that would run at Alfresco startup, check for the existence of the old node, copy its properties into the appropriate new nodes, and delete the old node.
Is such a thing possible? I've looked at the Bootstrap configuration file, but that appears to only allow one to add things to the repository, not modify or delete them.
My suggestion is that you write a patch. That is a class that implements
org.alfresco.repo.admin.patch.AbstractPatch
Then you can do pretty much anything you want on bootstrap (except executing searches against solr since it wont be available).
Add some spring configuration, take a look at the file patch-services-context.xml for inspiration.
Yes you can do that, probably you missed the correct place in the documentation about that:
If you open Import Strategy you'll find a section Per BootstrapView, you should be using something like REPLACE_EXISTING or UPDATE_EXISTING for your ACP packaged content (if you're using ACPs as your bootstrap importing strategy).
Here is a more detailed description of the UUID Bindings values.
Hope that helps.
You can use patches.
When alfresco server starts it applies patches and executes database updates etc.
Definition :
A patch is a piece of Java code that executes once when Alfresco
Content Services starts. Custom patches can be implemented.
Documentation Link
We are hosting huge app for our cutomers. There are diffrent configuration and contents (images, user files). But the core code, directories structure, databse scheme is this same for every client.
I'm looking for a way to create one core code repository, so all clientes will use it. We do updates often, so this will make our live easyer.
The idea is to create the repo and In clients directories create just symbolic links to that repo direcories: bin, App_Resources, Css, SystemImages etc.
Is this a good idea? Will ASP.NET MVC app handle this correctly, or I've to add some code for it handle the 'virtual direcotories'?
I would suggest that you take a look Single-tenant and Multi-tenant applications even if you say that your code base is the same for every one.
Here is a nice Multi-Tenancy ASP.NET example
I would also suggest that you check http://appHarbour.com as you can easily push changes from your master repository to appHarbour using Git or Mercurial.
Regarding your exact question, I also keep static files in a custom scheme under Amazon S3, so each client can upload there own files, plus the ones I have and all is based on a single location that does not put more resources just to delivery static files.
You can see my live web application using this technique checking the View Source.
I am fighting with Xcode 4 workspaces. Currently Xcode 4 wins. Thus, my situation:
I have the workspace with the iOS app project. There is also static library project iOS app depends on in the this workspace.
Solution #1
I try to configure like this:
the app project:
add to target's Build Phases > Link Binary With Library a product (libmystaticlib.a);
set USER_HEADER_SEARCH_PATHS to $(TARGET_BUILD_DIR)/usr/local/include $(DSTROOT)/usr/local/include;
the static library project:
add some header files to target's Build Phases > Copy Headers > Public;
set SKIP_INSTALL to YES.
And important thing: both projects must have configurations named the same. Otherwise, if I have, e.g., configuration named Distribution (Ad Hoc) for the app and Release for the static library, Xcode can't link the app with the library.
With this configuration archiving results to an archive with the application and public headers from static library projects. Of course, I am not able to share *.ipa in this case. :(
Solution #2
I have also tried another configuration:
Xcode preferences:
set source tree for the static library, e.g, ADDITIONS_PROJECT;
the app project:
add to target's Build Phases > Link Binary With Library a product (libmystaticlib.a);
set USER_HEADER_SEARCH_PATHS to $(ADDITIONS_PROJECT)/**;
the static library project:
don't add any header files to Public!;
set SKIP_INSTALL to YES.
I still need to care about configuration names for both projects. But in result I can build and archive successfully. In the result I get archive and I can share *.ipa.
I don't like the second solutions, because in this case I don't get any real advantage of the Xcode 4 workspace. The same effect I can add get, if I add the static lib project inside the app project. Therefore, I think something is wrong with my solution.
Any suggestion how better to link a static libraries?
I also found a solution that works with build and with archive.
In your static library set the Public Headers Folder Path to ../../Headers/YourLib
In your app config set the Header Search Paths to $(BUILT_PRODUCTS_DIR)/../../Headers
In your app you will be able to code #import <YourLib/YourFile.h>
Don't forget the Skip Install = YES option in your static lib.
We've found an answer, finally. Well, kind of. The problem occurred because Xcode 4 places public headers into InstallationBuildProductsLocation folder during build for archive. Apparently, when archiving it sees the headers and tries to put them into archive as well. Changing Public Headers Folder Path of the lib to somewhere outside of InstallationBuildProductsLocation, for example, to $(DSTROOT)/../public_folders and adding this path to Header Search Path solve the problem.
This solution doesn't look very elegant, but for us it seems to be the only option. May be you'll find this useful.
Here is a solution a get from Apple DTS. I don't like it, because it is suggests to use absolute path. But I still publish it here, maybe someone feels it is right for him.
How to set up the static library:
Add a build configuration named "Archive" by copying the Release Configuration.
Move your headers to the Project group of the Copy Headers build phase.
Set the Per-configuration Build Products Path of the "Archive" configuration to $(BUILD_DIR)/MyLibBuildDir. Xcode will create the MyLibBuildDir folder inside the BuildProductsPath, then add your static library into that folder. You can use "MyLibBuildDir" or provide another name for the above folder.
Set Skip Install to YES for all configurations.
Set Installation Directory of "Archive" to $(TARGET_TEMP_DIR)/UninstalledProducts.
Edit its scheme, set the Build Configuration of its Archive action to "Archive."
How to set up the project linking against the library:
Add a build configuration named "Archive" by copying the Release Configuration.
Set the Library Search Paths of "Archive" to $(BUILD_DIR)/MyLibBuildDir.
Set the User Header Search Paths to the recursive absolute path of your root of your workspace directory for all configurations.
Set Always Search User Paths of "Archive" to YES.
Set Skip_Install to NO for all configurations.
Edit its scheme, set the Build Configuration of its Archive action to "Archive."
I was not real happy with any of the other solutions that were provided, so I found another solution that I prefer. Rather than having to use relevant paths to put the /usr/local/include folder outside of the installation directory, I added a pre-action to the Archive step in my scheme. In the pre-action I provided a script that removed the usr directory prior to archiving.
rm -r "$OBJROOT/ArchiveIntermediates/MyAppName/InstallationBuildProductsLocation/usr"
This removes the usr directory before archiving so that it does not end up in the bundle and cause Xcode to think it has multiple modules.
so far I also struggled with the same problem, but did come to a solution with a minimal tradeoff:
This requires Dervied Data to be your Build Location.
I set the Public Headers Folder path to ../usr/local/include
This will ensure, that the headers will not be placed into the archive.
For the app, I set the Header Search Path to:
$(OBJROOT)/usr/local/include
$(SYMROOT)/usr/local/include
There are 2 entries necessary since the paths slightly change when building an archive and I haven't figured out how to describe it with only one variable.
The nice thing here is, that it doesn't break code sense. So except for having 2 entries rather than one, this works perfectly fine.
I'm struggling with the same problem at the moment. I didn't progress much farther than you. I can only add that in the second solution you can drag headers you need to use from the library to the app project, instead of setting ADDITIONS_PROJECT and USER_HEADER_SEARCH_PATH. This will make them visible in app project. Value of SKIP_INSTALL flag doesn't matter in this case.
Still, this solution isn't going to work for me, because I'm moving rather big project, with dozens of libraries, from Xcode 3 to Xcode 4, and it means really a lot of drag and drop to make my project build and archive correctly. Please let us know if you find any better way out of this situation.
I could use Core Plot as a static library and workspace sibling, with two build configurations:
Release:
in project, Header Search Path: "$(BUILT_PRODUCTS_DIR)"
in CorePlot-CocoaTouch, Public Headers Folder Path: /usr/local/include
AdHoc (build configuration for "Archive" step in Scheme, produces a shareable .ipa):
in project, Header Search Path: "$(BUILT_PRODUCTS_DIR)"/../../public_folders/**
in CorePlot-CocoaTouch, Public Headers Folder Path: ../../public_folders
Hope it will help someone to not waste a day on this.