I am using Sitecore 8, Update 3.
I am attempting to bulk create a couple thousand items that use a custom template. All of these items are created under one specific parent item.
The custom template has two fields which are Path [Single-Line Text] and Target [General Link].
The source of the data is in an old SQL database.
Is there a way to do this?
The Sitecore marketplace module Data Importer is a option for you.
Create a custom importer with the sitecore api is also possible, to speed up, you can disable the index rebuild.
Since your data is already in SQL Serve, you should take a look at using the SSIS Components for Sitecore, it was designed for importing exactly this kind of data in bulk into Sitecore using ETL.
You can find more info in the blog post Creating your first project with SSIS Components for Sitecore and there is also some good additional into in the Migrating to Sitecore: Going from WordPress to Sitecore with SQL Server Integration Services (SSIS) post.
The Integration Services Components for Sitecore is available on the Sitecore Marketplace, and it is compatible with Sitecore XP8.
I'll also add, if you are creating anything more than 100 items below a single parent item then this is not recommended Sitecore practice unless the items sit within an Item Bucket. Make sure you account for this, or split your items up into smaller sub-folders (e.g. year/month folders for news article type items)
In these scenarios you normally end up writing code to call the api and create the items programmatically rather than doing a generic import.
If you need to create a large amount of items I would recommend writing a console app to do this. You could use the Sitecore Item Web api to create items outside of the Sitecore context or investigate the new Entity Service api in Sitecore, both will be capable of creating large amounts of Sitecore items.
http://mikerobbins.co.uk/2015/01/06/entityservice-sitecore-service-client/
https://sdn.sitecore.net/upload/sdn5/modules/sitecore%20item%20web%20api/sitecore_item_web_api_developer_guide_sc65-66-usletter.pdf
If these don't float your boat you could always write async code to create the Sitecore items and have that executed by an aspx page in a Sitecore instance - works well for one off tasks.
Example of Asynchronous page processing in ASP.net webforms (.NET 2.0)
Related
I am trying to rebuild our website in Django, and I am currently facing a series of rather difficult challenges for which I am not prepared. I was hoping to get some help in the matter.
The website I am building is an online archival platform for artists called Lekha. The core of Lekha is the dashboard page (which you can check out on this link, just sign in with the email stacko#test.com and the password test if you have the patience).
On the dashboard page, users have access to a hierarchical filesystem that we would like to function like a desktop filesystem for ease of use. Users can use the filesystem to organize their 'artworks' into folders. These artworks themselves are a collection of media, along with the metadata of the artwork. To upload this media and fill in the metadata, users will use a form. If users want to edit an artwork's metadata, they can do so through an auto-populated form on the same page.
The issue that I am facing is that I am struggling to find an elegant way to make all of this happen without reloading the page. Users need to be able to add, delete, and rename folders in the filesystem without reloading the page (just like dropbox). They also need to be able to add 'artwork' database entries using a popup form, and edit 'artworks' they have created through an auto-populated form that is also served to them without reloading the page (as it is currently implemented on our existing dashboard page).
All of the Django tutorials I have seen delete items using a dedicated /delete/ page, but this would require reloading the page. Based on my research, the solution I am looking for has to do with asynchronous updating through AJAX.
I wanted to ask all the Django experts out there what the best way to go about this would be. Are there any best practices I should know about before going into this? We are building our website to be robust and scale well.
Are there any specific libraries for asynchronous stuff in Django that are best?
How do asynchronous websites scale if we have several users on them at the same time, and should I write the backend in any specific way to account for potential scaling issues?
What is the difference between ASGI and WSGI?
Are there tools that I can use such as htmx to make my life easier?
I am currently trying to develop a plugin in oracle apex. This plugin consists of attributes which have SQL queries. I want to pass this SQL queries into the child component. In this case the child component is a dialog window.
I can pass different values like numbers or strings easily as page items with the url approach. However using this approach is not very scalable because of the URL restriction of maximum 2000 characters.
e.g. with APEX_UTIL.PREPARE_URL
Therefore I thought of storing SQL-Queries in the database and then query it in the dialog.
And here is the problem: How can I store the SQL Queries when the plugin is configured?
I do not like to have the logic in the render call, because this way everytime the plugin gets rendered it makes some unnecessary database requests.
Is there something like an event when the page gets saved with the plugin? Or a possibility to have some PL/SQL code after the page gets changed which can access the plugin attributes?
We recently worked with a client to create a series of smaller sites that were composed of the same templates and components being developed for their main flagship site. These microsites needed to conform to a common layout but required the ability to have unique branding in the header as well as unique hostnames or domain names. Setting up a new site in Sitecore is a fairly straightforward process, typically – you create the new home node in the content tree then add a declaration to the web.config. In this particular scenario however, the client did not want to have to make a configuration update to deploy each new microsite – they simply wanted to create the content for it, publish it, and have it available to their audiences immediately.
I have gone through a link (https://www.sitecore.net/learn/blogs/technical-blogs/chris-sulham/posts/2015/01/quick-guide.aspx) but found incomplete information.
The general approach to solve this requirement is to store the site definition data in the Sitecore database as a 'site definition' of some kind. You will then need a processor that will initialize the sites list after the file configs have been read and update site definitions or add to the list.
#jammykam pointed to the Dynamic Sites Manager as an example of this, so you may want to start there.
Since authors typically define these new sites after Sitecore start-up, you also will need some functionality (usually a ribbon button or publishing event handler) that will let you trigger an update of the current site list in application memory with the latest data.
In my project I need to add a lot of custom entities to Typo3 CMS.
Eg. I need to have Buildings, Building Companies, Architects, Certifications, and so on.
What is the common approach for doing this?
Should I develop a new extension?
How can I then have a custom backend for managing these entities? Eg. in the Buildings admin page I want to be able to add a new Building also associating one or more Architects to it. Is it feasible? How?
Can I create a custom backend field for looking up Architects in the Buildings admin page? (eg. something like StackOverflow tags system, a token input field which looks up for items in Architects table in real-time while editing a Building)
To map a business model into Typo3 I prefer to build an extension for that.
On the one hand you have the maximum flexibility by programming in PHP with the help of the Typo3 framework and on the other hand most of the backend management pages come in easy when using the standard MVC + TCA structure of Typo3 Extbase extensions (if it is your first try with Extbase you might want to have an Extbase book at hand).
You can have a look at the Typo3 TCA page to see which standard backend field types are available - there are shown a lot of example configurations. As in your case you might want to use a select field with property "size" > 1 and property "maxitems" > 1 to describe the relation between buildings and architects. As for the architects filter feature you might also want to add the property "enableMultiSelectFilterTextfield" as shown in this example.
We have a couple of MVC 3.0 web application some of them combination of Web Form and MVC3.0 within on project/solution.
I'm quiet new to sitecore, could someone please help me understand following in regards to migrating the existing application to Sitecore?
On what type of scenarios should we move MVC3.0 razor views to sitecore?
What are the key gotchas migrating MVC3.0 to sitecore?
Do I need to inject anything on sitecore pipeline?
Do I need to change any of the navigation links to work under sitecore?
Any link to sitecore best practice for migrating existing web app will be good.
I followed the blog below and still unclear why and when should we convert web control and razor views to Sitecore Rendering.
Thank you.
When migrating MVC applications into a Sitecore solution you have a few options available - depending on the nature of the component you are migrating you would have to choose the most appropriate option.
I'll try and address your 5 specific questions:
1. When to use Razor views
I'm not sure if the question is "when to use a Razor view" or if the questions is "when to use Sitecore View Rendering" - I'll assume the latter.
A View Rendering is great if your are writing presentation components that do not require any business logic and only deals with rendering items. If you are contemplating adding code in your Razor view you should probably consider if a Controller Rendering would be more appropriate or perhaps customising the mvc.getModel pipeline.
2. Migration gotchas
Some of the things that may catch you out when migrating a MVC application to Sitecore.
Component based controllers - in MVC you have one controller per page. Sitecore supports the concept of ControllerRenderings that allows you to have multiple controllers on a page (note: there will always be one route controller that can be perceived as the primary).
Item routing - Sitecore has a catch all route that is effective for all paths that map to an item path. Standard MVC routes and "item routes" can happily coexist. Item routes do not currently support route parameters (e.g. you cannot specify {action} or other parameters on the item route).
MVC4 - Currently no official support for MVC4 (this won't hold true for long - but in the meantime have a look at http://herskind.co.uk/blog/2012/10/sitecore-66-mvc4)
Areas - Currently areas are not fully supported.
Not knowing what rendering types to use and when to convert existing functionality into components.
3. Pipeline customisation
You are not compelled to customise the Sitecore pipelines. I can see a few examples where it would be useful to modify pipelines in the context of a migration story. One example I recently talked about at a Sitecore User Group involved adding a ActionFilter globally (through mvc.resultExecuting pipeline) that would inject a ASP.Net MVC application into a Sitecore place holder. In my example I injected the MVC Music Store into a placeholder and had Sitecore control window dressing (headers/footers/menus). This way I could bring my existing MVC application into Sitecore without having to change it much.
4. Navigation links
If your navigation endpoints are Sitecore item routes (e.i. the path to an item on the website) you should use Sitecore's LinkManager to generate the appropriate links. If the endpoints are standard MVC routes RouteLink and ActionLink should work just fine.
I guess without a concrete example the answer will be "maybe".
5. Best practice migration blog post
I'm not aware of any blog posts or articles dealing with Sitecore MVC migration best practice. Keep in mind that full MVC support is a recent addition to Sitecore and not many seen this journey from start to end yet.
Why and when to convert to Sitecore Rendering
You end your question stating that you are still confused about when and why you would convert controls and Razor views to Sitecore renderings. Here are some indicators that something is a candidate for being a Sitecore rendering:
It is a component that can be reused on many pages.
You want to enable Sitecore users to add the component to pages. (think Page Editor)
You want to leverage Sitecore's component level caching.
You want to leverage Sitecore security to restrict who can use/see the component.
You want to control the component with personalisation, rules or run MVT on it.
In the context of MVC here are some indicators that it may not be right to convert something to a Sitecore rendering:
It relies heavily on routing and route parameters.
I'm sure many of the points in this answer could be expanded on and I know that there are no clear cut rules for this - but I hope this answer helps clear up some of the confusion...