[Andrew]

Hi all,

I have a layout that renders a right sidebar using `$this->render_block('right_sidebar')`. In my page I have a right_sidebar block in which I place `<? content_block('my_content', 'My Content')?>` but I'm not getting the "Edit Content" menu item in the admin UI.

I'm using file based templates and have seen a post mentioning the "must save in editor bug" but this doesn't seem to work with content defined in "Heads & Blocks".

Any ideas?

Thanks & cheers
Andrew

[Aleksey]

Hi Andrew,

LemonStand doesn't recognize content blocks declared in blocks. Please consider using global content blocks (see CMS/Content tab).

Thank you

[Andrew]

Hi Aleksey,

Aleksey, on 22 January 2012 - 03:27 PM, said:

LemonStand doesn't recognize content blocks declared in blocks. Please consider using global content blocks (see CMS/Content tab).

The issue with global content blocks is it's one big flat list (which isn't that nice for my clients) and they don't get persisted to the file system (since I use a VCS for deployment).

Is this something that would be hard to change? Other wise I have to create a page using a layout with render_block calls, create blocks within the page that then reference global content blocks and then create global content blocks as well. Using straight blocks is not an option since it exposes my client to HTML. It's all a bit clunky.

This also raises other issues that I'm facing, namely that I use a VCS for deployment and there are CMS/theme things that can only be done from the UI. For example not all database settings are exported to the files system, so if I change a page layout on dev I have to remember to do it in production which is a *huge* pain. Global content areas are another one.

It would be great if there was a file like <my_page>/page_settings.php that contained these settings and the global content was also stored in the file system.

I have been seriously considering if I just go down the CMS import/export path but I still want to deploy my LS itself and any custom modules using my VCS which leaves me with my dev environment with code based templates which will be checked in and DB based themes on production which sort of sucks. That and it just feels wrong.

The concepts here are handled pretty well by the CMS I use (Concrete5) since themes/configuration are fully file based and content is fully DB based. I can suck the user content down, make changes to my code, test and push my code back up and everything just works. I can also push new content up from dev if I co-ordinate it with my client so we don't clobber each others data. It's quite similar to LS but it separates the notion of a page from a page type. All code aspects are defined in the page type and the page itself if a pure DB entity that is assigned a page type and holds the user content for the various content_block styles includes. There is a clean separation and the approach works very well. In fact I wish Concrete5 had the code quality Lemondstand (it's a looong way behind) and that Lemonstand had the code/db separation of Concrete5! It's a cruel world.

Anyway I realise this has been discussed a lot and resources are limited but my ideal wish list would be:

• Strictly no development work or system updates are made directly on production.
  
• All code changes are fully version controlled (whether in themes, custom modules etc) - i.e. no code or site specific configuration in the DB.
  
• Ability to pull user content from production so I can sync dev to production & do full testing in all browsers before pushing changes back to production.
  
• Deploy system & theme changes using version control with no post deploy configuration like setting layouts on pages (or anything else I could possibly forget about).

For a start though just having all page settings and global areas stored in the file system would be a huge help.

Thanks & cheers
Andrew

[Aleksey]

Hi Andrew,

Thanks for your ideas. I posted them to our internal list for the future consideration.

I just discovered a trick that allows you to use content blocks inside page blocks. You should define the content block both in the block and in the page content, but in the page content code the block should be commented out. The CMS can recognize content blocks even when they are commented out. Example, block:

<? content_block('test_content', 'Test content')  ?>

Page content:

<?
  	// content_block('test_content', 'Test content')
 ?>

When the block is rendered inside a layout, it properly outputs the content block. I know, this is a dirty method, but we can't add support for content blocks inside blocks right away.

Thank you

[Andrew]

Hi Aleskey,

Aleksey, on 23 January 2012 - 03:12 PM, said:

Thanks for your ideas. I posted them to our internal list for the future consideration.

Cool, thanks for thinking about them.

Quote

<?
  	// content_block('test_content', 'Test content')
 ?>

When the block is rendered inside a layout, it properly outputs the content block. I know, this is a dirty method, but we can't add support for content blocks inside blocks right away.

Cool, that will work for me for now, I'll just comment it appropriately (c:

I'm also thinking I'll try deploying theme's using export/import for now, so I'll see how that goes.

Thanks & cheers
Andrew