Working on a project for a client. They have a PDF that has been broken into separate pages as images, and they want to have each of those images appear on a single page - at least 40 images for this one page alone.
So far, I've just been placing them individually. Each time you go to place an image using the rich editor, you start at the media root - and the way the media library has been structured, these images are buried very deep within subfolders. So it takes about 20 seconds of clicking, scrolling, and reading to find each image to place it.
These images are sequential and placed in order in the media library. Is there a way I can select a group of images and just drop them in? There are going to be literally hundreds of these, and it's a huge waste of my (and my client's) time placing images one-by-one.
Going along the lines of what TwentyGotoTen has said, I would:
Structure your images in the Media Library within folders (if you haven't already done so)
Create a sublayout/xsl rendering that contains a repeater to render the images
Add the control to the layout and set the DataSource of that control to the Media Folder
The code should then retrieve all child items from that folder and render as necessary.
You may need the use of the Sublayout Parameter Helper to access the datasource from ascx codebehind.
I'm assuming you just want the images to appear one after the other with nothing else inbetween. Rather than embedding images in rich-text perhaps you should consider creating a multilist field for the images in the template and create a rendering / sublayout to render them.
You can set a more suitable source for the multilist than the media root. This should make it a lot easier to select the images.
Mark van Aalst has created a custom image field that allows to do this a bit easier as well.
Have a read through this. This is also available on Sitecore's Marketplace: Multiple Images Selector
It will allow you to select your images through a multilist field, but it'll show the images as an image field with multiple images.
I think this is pretty much the solution TwentyGotoTen is talking about as well, but shows the thumbnail of the selected images as well.
Related
Is there a django wysiyg editor I can control its image?
I want to set a default image size and use the image as a thumbnail as well.
all wysiyg contents are represent like {{content}} since in model it's set like
content=some Wysiyg field()
The one I want to do is {{content.image}} and play around with that image.
Is there any way I can do that? right now this is the one I'm using, but I'm willing to change to the one I can control image with.
try django-ckeditor, redactor it's more simple but redactor itself isn't free and i think ckeditor is more flexible in the configuration
I'm trying to understand the best approach to create article items in my sitecore 7.2 project.
Basically I'm considering 2 options:
1 - Create an article as a page;
2 - Create an article as a Site Data Item.
1 - Create article pages under a given page (i.e. My Articles). This way each article would have a specific URL out of the box, easier to understand in Content Authors' point of view;
2 - Have a specific folder (i.e. Article Folder) under Site Data. This way we don't need to have a page for each article - I was thinking to have a single Article page that would render the article fields. However this would require more work in terms of URLs, navigation, etc.
Is there any other ideas? Am I missing something? I was also having a look at Buckets...
Thank you
I'm going to disagree with Marek and recommend you opt for option 2.
Storing your articles in folder under a Data node allows those items to be datasourced. This is the principle Sitecore was built on. You can then surface those articles in a number of interesting ways via Widgets such as Promo Panels, prompting the user to click through to read about the article without duplicating its data and requiring Content Editors to manage data multiple times.
It even supports multiple sites, so the Articles can be used in other sites you may add to your Sitecore instance in the future.
As you state it will require extra work in terms of Urls and Navigation but it can be achieved via Sitecore's Wild Card Item and you an even use a great open sourced Module from Sitecore's Marketplace to complete 90% of the work for you. See links below for more information.
You can still implement Marek's point of applying Presentation Details once on the Standard Values of the Wild Cart Item you create. If you are using Sitecore 7 and above you can store all your articles in a Bucket so if you have lots of articles they are stored and searchable in a meaningful way.
http://www.sitecore.net/learn/blogs/technical-blogs/getting-to-know-sitecore/posts/2011/09/wildcards-and-data-driven-urls.aspx
https://marketplace.sitecore.net/en/Modules/Wildcard_module.aspx
In a standard one instance setup the easiest implementation is to create articles as pages.
In Sitecore you want to limit the items in a folder to 100 or less which is best practice to keep the content editors experience optimal.
This then leads you needing a folder structure and a couple options:
Manually maintain a folder structure for your articles. For example articles/year/month/day. This gives your editors the most control over the folder structure and allow them to navigate the articles in a more traditional way via a visible folder structure.
Use a bucket which automatically generates the folder structure and hides this complexity from the content editor. This takes the manual folder creation and maintenance away from the content editor and are automatically generated based on the configuration you set out for your bucket. The folders wont be visible to the content editor so they will be forced to search in the bucket for any articles rather then navigate the folders.
Use the shared source News mover module (https://marketplace.sitecore.net/en/Modules/News_mover.aspx). This takes a different approach to the above. It works via a traditional folder structure however it generates folders and moves the item on save based on the date field in the article. So the news mover handles the generation of folders however you will still need to check your not exceeding 100 items per folder again for performance when opening folders with large amounts of items.
With all solutions you must still consider the URLs for your articles as they will include the folder structure by default. This is not always acceptable. I prefer to remove the folder structure from the URL. For this you need to create a custom linkProvider and a custom HttpRequestProcessor. Firstly the linkprovider allows you to ensure the new URL is always created and displayed in your site as you want. Next the HttpRequestProcessor ensures that when navigating to the shortened URL Sitecore recognises it as a valid URL and presents the correct page.
By excluding the folder structure from the URL it also adds the additional benefit that the URL is not dependent on the structure. This means editors can change that folder structure and not need to create redirect items to ensure SEO rankings or users bookmarks are not lost.
The cleaner data model is to use the wildcard approach for the URLs and centralize the storage of articles data in a bucket of datasources. This will give you optimum performance and reuse of the data.
However, this isn't how an author thinks about their website. When they use the system, they tend to navigate to the area where they would view articles and try to create a new one there. Authors tend to think in 'pages', so try to hide whatever data model you are using from them and give them the ability to edit the page with Experience Editor.
Some developers try to optimize too far and forget that the authoring experience is likely the most important piece of the delivered solution. The author doesn't care how efficiently you stored the data, only that they can edit it easily and publish efficiently. Whatever model supports that for your author base is how you should implement it.
My recommendation is a page-based approach where the author creates the URL structure with folders and items, something they understand. Then, if you really need to, you can have the primary article data be a datasource-driven component on the page. The user gets to use all the tools they are familiar with (Experience Editor,preview navigation) but you can still store the raw data in a centralized folder. You could then theoretically swap out the article data using DMS rules, or hide information based on authentication or membership status.
Go with approach 1: article is a page.
Define all your presentation details on Article Page template __Standard Values. All new articles will get them. And you can change some of the presentation details for your chosen articles if you want.
If you know that you'll have lot of articles, think about year/month/day folder structure, e.g. articles/2015/06/12.
Approach 2 doesn't give you anything - you still need to have an item for every article. And as you wrote, it would require additional coding which is not required.
For a website we're working on, we had a pretty complex design to support. So, we chose the strategy where all content on each page is made up of components. Authors can insert various components such as a heading, rich text block, images, etc, allowing them flexibility in laying out pages. This was the only away we could support the complex design that was created.
This set up is working well except when it comes to versioning and search. When pages are versioned, the components on the page are not. When items are indexed for search, the components on the pages are not being indexed as part of the page. We think we may be able to solve the search issue with a custom search index, but the versioning issue seems much more complex.
Has anyone else faced these issues or have thoughts on solutions? We're on Sitecore 7.5.
A simple answer would be to upgrade to version 8 as soon as its released as version 8 will add versioning to the renderings field.
My Guess is that you are setting the content of the fields on the rendering parameters of each item? If that is the case I would suggest taking a slightly different approach. Use DataSources. You could have a few templates that hold the data, e.g. RichTextTemplate, SingleLineTextTemplate, ImageTemplate - all with a single field in, then when you add a heading or rich text block to the page, setup the rendering to all the editor to create the data source.
This way all the content can be versioned properly and you are still separating your content and presentation.
To keep the tree un-cluttered, we use an "Assets" folder under the item for all content:
Example Tree:
Sitecore
Content
Home
Assets
Page 1
Assets
Heading
Rich Text Block
Page 2
Assets
Heading
Rich Text Block
Image Block
etc...
The search problem sounds similar to this post: How to index sub-content in Sitecore with Lucene?
That suggests a computed field. In your computed field, check that your template is a page and then get all the renderings for that page. Once you have those, get the renderings DataSource items and you can build a big search field using the content from the DataSource item's fields.
This would save having an extra index with a custom access layer. It all stays within the Sitecore API.
I have become a bit confused on the best way to move forward with something I'd like to achieve in Wordpress. My problem is partly workflow I think and knowing the correct way to do what I'd like to achieve but also there may be a few blanks on how to actually implement some of what I need to do. I have checked various online resources but they all are specific to what they are doing and I can't easily understand them to apply them in to the context of my own project, which is why I wanted to ask here. I'm sure my initial question will inevitably branch out to sub questions but here we go:
For my website I have created a custom post type called 'projects'. I have successfully set this up.
Then for each project I need to allow the following data to be entered:
Project Title
Project Description
Also post meta data that will display as a list on each project page (I'll need to display both the key and value on the page but only for those fields that contain data 'i.e. I don't want the list to show as Location: blank'):
Client Name:
Location:
Project Value:
Architect:
Engineer:
Site Area:
My main question is this, I need to show images for each project and allow the user to select a 'template' for each project post, this is because there are about 5 grid designs for layout of the images (1 main Image, 1 square image with two small images right side, 3 portrait image cols etc).
I thought the correct way would be to create a custom post type called projects, add write panels to allow easy input of data (I've yet to add image uploads as this will need to vary depending on the template selected and number of images required), at data input stage the user selects the preferred image layout/template and then uploads images for the containers that allow images (I’ll need to id each image upload to position it in the template with CSS, that was the plan).
Firstly, am I approaching this correctly? And secondly, how can I add functionality to the write panel I have created to allow users to a) select a 'Template' (bit like you can with pages but for my custom post type) and b) to add image upload fields which change depending on the template selected?
Finally, I would like to stay away from using plug-ins and try and achieve this myself through functions.php etc. This is to avoid problems later as plugins update or lose support etc.
Any help is appreciated, thank you.
This sort of question seems to come up a lot in regards to Wordpress (I answered essentially the same question the other day). I know you want to avoid plugins but this sounds like a job for Advanced Custom Fields.
You can create exactly the fields you need for your custom post type (including an image upload field), and then add them into the template the corresponds with your custom post type.
ACF does have a 'lite mode' which can be included directly in a theme. This way you needn't worry about updates nuking site functionality. Believe me you will save yourself a lot of time and energy this way.
It's admirable to try and do it with pure WP, but it's a maturing platform, it just doesn't lend itself to this sort of customization easily.
I am building an application that allows a user to browse html templates. The html template will be displayed in a preview area (source code will be obfuscated), and although the template will contain inline CSS/JS, there will also be the odd linked image asset.
For this reason, I thought it might be best for me to just store them as a library of folders, and retrieve the flat file from my server for display, as opposed to storing the HTML in the database and having to organise the external assets too.
My question is: Where in the CakePHP directory structure, is the best home for these files? I'd rather keep them above the webroot, and I'm thinking View.
Any ideas? Thanks.
I would suggest that you keep all the out-of-cakephp-framework related files, stored under the webroot.
My suggestion is the following directory structure for saving the html template as well as the css and js related files.
/webroot/files/templates/<template-project-name>/<the-actual-file>.html
Any external css, would then be under
/webroot/css/templates/<template-project-name>/<the-actual-css>.css
And the JS libraries would be under
/webroot/js/templates/<template-project-name>/<the-actual-js>.js
Use a seperate layout file (call it preview_layout.ctp) which simply renders
the template file as it is.
Hope it helps
Why do you want to store them above the webroot, when they are publicly-viewable assets? My gut feeling is that they really belong in the webroot or in the database. I would pick one or the other.
If you must store them above the webroot, I guess the best thing might be to store them as elements.
app/View/Elements/your_templates/
And that way, you can load it into the preview area of your View using:
echo $this->element('your_templates/template');
Edit:
Honestly, the suggestion of elements is not what I would recommend, I'm just trying to offer you different suggestions. It would be terribly bad practice and I think it will be more messy and problematic than it's worth.
As for the image files, put them in the webroot, regardless of where you choose to store the HTML templates. You can't stop people downloading the images once they are viewing them in their browser anyway.