I'm trying to integrate N2CMS into an existing application. I'm in the middle of the installation and have been following the documentation supplied for integrating into an existing application.
I'm up to the 'Add Content Package' part of the installation'. However, the 'HomePage' start page is not appearing under the 'start node' drop down list (under 'Manually Insert Nodes'). I've been trying to figure this out for a few days now, looking at various sources but nothing seems to work.
I'll post the Content Item below (the cs code that the installer should be picking up on). All I really need is a CMS that is easy to integrate into an existing website, which is why I went with N2CMS. But the poorly maintained documentation and lack of support really makes me want to try something else. Unfortunately every CMS wants you to use their system from scratch. If anyone knows another Open Source CMS which is easy to integrate into an existing website, please let me know.
Here's the cs code (HomePage.cs, under the 'Models' Folder)
namespace ExistingApplication.Models
{
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using N2;
using N2.Web;
using N2.Details;
using N2.ContentItem;
using N2.Installation;
[N2.Definition("My page", "MyPage", "A simple page with a chunk of text", "The tooltip", 1, Installer = InstallerHint.PreferredStartPage, TemplateUrl = "~/UI/Home.aspx")]
[N2.Details.WithEditableTitle, N2.Details.WithEditableName]
public class HomePage : N2.ContentItem
{
}
}
By the way the url that 'TemplateUrl' points to does exist. Thanks in advance.
Try modifying HomePage definition by implementing (empty) interface IStartPage
public class HomePage : N2.ContentItem, IStartPage
IStartPage is marker interface that is used exactly for this purpose - so that N2 can distinguish regular pages from those that can serve as Start Page of the site.
Related
i defined a hook in ext_localconf.php:
$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_content.php']['typoLink_PostProc']['titleTagsInHiddenText'] = SNM\StmwiAccessibility\ExtendTypolink::class . '->convertTitleInHiddenText';
This hook will be executed on every link on the page, on all pages of all sites. This could be a performance killer ...
So, is there a possibility to restrict the use of the hook to the actual page? Is it possible to get the current site in ext_localconf.php?
e.g.:
$currentSite = ????;
if ($currentsite = 'rootPidOfMySite') {
$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']
}
This question rises in other contexts too: i often want to restrict the performance consuming configuration of extensions to one single site. I can do it with the static setup file but not with the stuff in ext_localconf.php.
Thanks!
Which TYPO3 version do you use? There is an API to access the site configuration. I'd say you need to register PSR-15 middleware and then you can access the site configuration. More details can be found in the documentation.
Whenever we are doing the static content deploy in magento2 instance in ubuntu environment.the generated folders create with following permission
0770 and so that when we are browsing via URL the page is not loading, I have tried in many ways of work for it , what magento2 freak guys doing for this kind of scenario rather giving the manual permission to the folder when it is created, the Following class is responsible for the creating the folders with permission.
This is default driver interface class
Magento\Framework\Filesystem\DriverInterface
const WRITEABLE_DIRECTORY_MODE = 0770;
This below class is used for the file generator
Magento\Framework\Code\Generator\Io
This function is used for creating the directory
private function _makeDirectory($directory)
If you have any suggestions or idea post it now.
We changed the way Magento sets file system permissions in 2.0.6. What version are you using?
We now do not set permissions on static files or anything else. For more information, see this.
I am working on migrating a legacy CMS onto EPiServer CMS. I want to move the content from legacy CMS into EPiServer's database. Anyone ran into a scenario like this? I followed their document on world.episerver.com, but it is not very clear. It says to configure EPiServer site under config tab in Admin section to define Content Channel. But they do not talk about exactly what APIs to use and how different fields map in their database to EpiServer's database. Any help would be much appreciated.
You should not copy directly into the database since it is extremely difficult to get it right.
You need to start by building up your content types inside your project and then I think the easiest way to import the content would to build scheduled task or extend the admin interface with a import page.
In that you do your own mapping since you are the only one that knows what the things in the old CMS should be in EPiServer.
This is not an easy thing to do if you are new to EPiServer and I think that it might be the quickest way to contact expert services and they will then help end guide you.
Good luck!!
You can add page programmatically using EpiServer's IContenntRepository and IContentTypeRepositoiry as follows:
using EPiServer.Core;
using EPiServer.DataAbstraction;
using EPiServer.DataAnnotations;
using EPiServer.ServiceLocation;
PageReference parent = PageReference.RootPage;
IContentRepository contentRepository = EPiServer.ServiceLocation.ServiceLocator.Current.GetInstance<IContentRepository>();
IContentTypeRepository contentTypeRepository = EPiServer.ServiceLocation.ServiceLocator.Current.GetInstance<IContentTypeRepository>();
PageData myPage = contentRepository.GetDefault<PageData>(parent, contentTypeRepository.Load("StandardPage").ID);
StandardPage standardPage = contentRepository.GetDefault<StandardPage>(parent);
myPage.Property["PageName"].Value = "Name";
myPage.Property["MainBody"].Value = "My Page";
myPage.Property["PageTypeName"].Value = "Standard Page";
myPage.Property["PagePendingPublish"].Value = true;
myPage.URLSegment = EPiServer.Web.UrlSegment.CreateUrlSegment(myPage);
contentRepository.Save(myPage, EPiServer.DataAccess.SaveAction.Publish, EPiServer.Security.AccessLevel.NoAccess);
I've started investigating alternatives to my project and a few questions came out that I couldn't answer by myself.
The problem is: I want to create a web page able to access multiple Magento instances installed in the same server. Currently, I have one Magento instance per client and this project will access several Magneto instances to export reports from each one (for example).
The alternatives I thought til this moment are:
Have another Magento instance, create a new module within it that changes its 'database target' before triggering operations/queries;
Questions until this moment:
Can I 'change the database target' of a Magento instance?
How can I access data from a Magento instance without appeal to SOAP/REST?
I want to re-use some components (grids, tabs, forms..) from Magento, that's why I'm not considering an independent project (Zend, for instance) that can access this code from another projects. Does it make sense?
Any other idea?
==Edited==
Thanks by the tips and sorry by my ignorance. The comments let me believe that I'm able to execute something like this:
// File myScript.php
require '/home/DOMAIN1/app/Mage.php';
Mage::app('default');
// get some products from DOMAIN1
require '/home/DOMAIN2/app/Mage.php';
Mage::app('default');
// get some products from DOMAIN2
Is it right? Can I execute require twice (and override things from first require)?
==Edited2==
I'm still trying to connect to several Magento instances from a single third party file. Is there any tip? I'm facing several/different errors at this moment.
The only thing I know is that I can still rely on SOAP to get the information I need, but this will be expensive.
Thanks!
The easiest way would be to include Mage.php from each shop instance. You would need to use namespaces or some other trickery to be able to load more then one.
Or if that doesn't work - make your own API in a separate file to get what you want from one shop, and combine the results in the PHP-file that calls the API.
Here's a sample on how to use Magento functionality outside of Magento:
require 'app/Mage.php';
if (!Mage::isInstalled()) {
echo "Application is not installed yet, please complete install wizard first.";
exit;
}
Mage::app()->setCurrentStore(Mage_Core_Model_App::ADMIN_STORE_ID);
// your custom code here, for example, get the product model..
$productModel = Mage::getModel('catalog/product');
We're thinking of converting our PHP Webapp from using no framework (which is killing us) to use Zend Framework. Because of the size of the application I don't think starting from scratch is going to be a viable option for management so I wanted to start researching how to slowly convert from the current site structure to one using Zend Framework but there isn't a lot of information on this process.
So far my plan is to dump the current code base into the public/ directory of the Zend Application, fix the numerous problems that I'm sure this will crop up and then start rewriting modules one at a time.
Has anyone had experience doing this in the past and how did it work out for you?
I've done a few of these now. What worked best for me was putting ZF 'around' the old app, so all requests go through ZF. I then have a 'Legacy' controller plugin, which checks whether the request can be satisfied by ZF, and if not, sends it to the old app:
class Yourapp_Plugin_Legacy extends Zend_Controller_Plugin_Abstract
{
public function preDispatch(Zend_Controller_Request_Abstract $request)
{
$dispatcher = Zend_Controller_Front::getInstance()->getDispatcher();
if (!$dispatcher->isDispatchable($request)) {
// send to the old code...
}
}
}
exactly how you then send the request to your old app depends a bit on how it is implemented. In one project, I examined the request, determined what file from the old code the request would have gone to, and then required that in. It sounds like this might be appropriate for you. In another project my solution was to route all these requests to a LegacyController in the ZF project, which ran the old code to get the resulting HTML and then rendered it inside the Zend_Layout from the new project.
The advantages of this approach are that you can gradually introduce ZF modules as you rewrite parts of the old app, until you reach the point where 100% of requests can be served by ZF. Also, since the ZF project has initialized before your old code is run, your old code can use the ZF autoloader, so you can start replacing classes in the old code with models written in a more ZF-style, and have them used by both parts of the app.