The Big 1.0

[ghost]

Got comments/questions/suggestions? Leave them in the comments and we'll add them in when we can.

So, we just hit 0.8, and we're getting ever-closer to the big launch. Only seems fair that we have a big checklist for 1.0 (as well as the other issues here).

Features:

• [ ] Plugins
• [x] Idiot-proof installer. Let's crush all these bugs that keep popping up.
• [x] Simplified UI (more on that).
• [x] Drag-to-add media (drag a file to the screen, add/detect type).
• [x] Simplified/smarter themes
• [ ] Full documentation.
• [ ] A simple API
• [ ] Mobile view/iOS app (but probably not the latter)
• [x] Markdown WYSIWG (bold/italic/etc. toolbar, very simple)
• [x] Namespacing table names.

Bugs:

• [x] Search functionality
• [x] content directory
• [x] mod_rewrite issues.

UI:

By 1.0, it'd be nice to have a consistent, super-minimal UI framework across both Anchor and Roar. The goal is to:

• Remove as many decisions as possible
• Remove as many obstacles as possible
• Be as simple and usable as possible

That means we're going to need the computer and server to do a bit more thinking, but this could be the best-designed CMS out there.

[daviddarnes]

Awesome, so psyched for this. Must discuss my side project with you (which you're aware of).

Couple of suggestions:

• Tick box dropdown custom field types
• Ability to add custom fields with the functions file, stops a theme with special fields being database dependant

[GiovanniK]

Great news!

Waiting and waiting for it!

[ZackBoe]

Looks like a solid roadmap so far. +1 on David's suggestion for theme specific custom fields. Perhaps the option to add a short description when creating custom fields, to be shown on hover when creating posts?

[daviddarnes]

Tags possibly? So you can mark several posts several attributions. Unlike categories which is more a filing method.

[iangcarroll]

If needed, I can help host one of the mirror's for the plugin repo.

[ryansnowden]

• Commenting code ;)

[matthewmorek]

Mobile view FTW. That would be awesome. Simple API would be great too!

Auto-update would be cool, but only if we could modify/override some core functionality from within the theme. Until then, I wouldn't like my site to "auto-break" every time a new version comes out.

[chrisgwynne]

The ability to export the CSS/JS inclusions to external files rather than having it inline.

[daviddarnes]

@chrisgwynne export? Do you mean when uploading a js or css file you'd like to be able to reference it for a post rather than using a style block? Those fields are for minor additions and special cases, not entire re-theme of a site.

[chrisgwynne]

@daviddarnes like on VisualIdiot.com for example, each post has its own styling and has it's CSS/JS saved as such "/posts/mailappapp/style.css" or "/posts/anypost/style.css". Having inline CSS/JS is always bad.

[saltandvinegarcrisps]

@idiot uses custom templates all together so instead of article.php there will be a template like article-mailappapp.php, correct me if im wrong.

[daviddarnes]

If the theme is made as expected the styles will be placed in an internal style sheet and the same for the js, which isn't inline. And yes if you wanted to do completely custom pages you could create a custom article file.

[laurensdeb]

Custom HTML would be a nice addition as well, the default editor isn't that handy when you try adding custom UI elements like the ones in twitter bootstrap.

Laurens

[daviddarnes]

You can write html as well as markdown in the main content area?

[saltandvinegarcrisps]

Yep

[laurensdeb]

I already knew that (markdown accepts xhtml) but sometimes it can be annoying that markdown auto processes your html as plain text.

Laurens

[dechuck]

The possibility to create different post type.

[borisovg]

Add "more" tag to hide part of a post when browsing list of posts.

[simoncla]

@dechuck what would you use this for? essentially every post/page can be whatever you want them to be.

@borisovg This can already be done using post description

[borisovg]

@Simonclavey so post description is what will show in the list? And if it's blank then the whole thing is shown? If so that's cool. :-)

[simoncla]

@borisovg Post description shows the snippet of text you add to the desc field on the post page. By default if there is no desc nothing is shown but it would be easy to add a quick if else statement to display whole post if desc is null. (this is going a little off-topic)

[borisovg]

@Simonclavey So the desciption is only shown in list view, not on the post itself, which is not the same as the "more" tag. To get the desired result I would have to copy paste a part of the post into description, which means duplicating content. :-(

[simoncla]

@borisovg O okay so you just want to show a snippet from the actual article. Just make a new function that returns the first ~140 characters of all your articles on the post loop page.

[ghost]

@borisovg OK, getting very off-topic here, moved it to #298.

[saltandvinegarcrisps]

In 0.9 we change the article_description function so that if you enter a short desc it will use that if not it will get a snippet from the content, I think this was discussed on the forums too.

[dechuck]

The advantage I will see is for client. Exemple, you have to different type of post, one is blog post and the other projet. The two different type of post have different custom field. They also have different permalink.

[daviddarnes]

@dechuck I think extra post types would be better suited as a plugin. Good suggestion though.

[dechuck]

@daviddarnes I like this solution.

[KevinGimbel]

I'd like to have most things (like the custom post types with custom URLs) as a plugin so it keeps the base CMS small and fast as it is.

The more you add everything to the core the more it becomes overweighted like most other CMS with lots of built-n stuff.

What do all others think? Built-in or rather plugin? In my opinion plugins are the better solution and for sure a good documentation of all plugins like anchor Themes - could also host it on Github or at least creat a respo so everyone can fork and add their own plugins.

[matthewmorek]

I think this is a great idea, as having a modular CMS will make it easy for everyone to tailor it to their own needs.

You don't care about SEO? Fine, you don't have to! You want a grea homepage slider? There's a plugin for that!

The above situation would be ideal for most cases, and I agree with @Kevin.

Let's keep it simple, stupidly simple.

Sent from beneath my fingertips

On 20 Apr 2013, at 09:41, Kevin notifications@github.com wrote:

I'd like to have most things (like the custom post types with custom URLs) as a plugin so it keeps the base CMS small and fast as it is.

The more you add everything to the core the more it becomes overweighted like most other CMS with lots of built-n stuff.

What do all others think? Built-in or rather plugin? In my opinion plugins are the better solution and for sure a good documentation of all plugins like anchor Themes - could also host it on Github or at least creat a respo so everyone can fork and add their own plugins.

— Reply to this email directly or view it on GitHub.

[dechowdev]

Will it be possible to Create a plugin hooking into core and make a custom post type?

If so it would be ideal if "post" class should simply called with a extend in order to intiate a new class for a post type... If possible(?) — Im Mobile, if I reply later than expected I apologize

On Sat, Apr 20, 2013 at 11:02 AM, Matthew Morek notifications@github.com wrote:

I think this is a great idea, as having a modular CMS will make it easy for everyone to tailor it to their own needs. You don't care about SEO? Fine, you don't have to! You want a grea homepage slider? There's a plugin for that! The above situation would be ideal for most cases, and I agree with @Kevin. Let's keep it simple, stupidly simple. Sent from beneath my fingertips On 20 Apr 2013, at 09:41, Kevin notifications@github.com wrote:

I'd like to have most things (like the custom post types with custom URLs) as a plugin so it keeps the base CMS small and fast as it is.

The more you add everything to the core the more it becomes overweighted like most other CMS with lots of built-n stuff.

What do all others think? Built-in or rather plugin? In my opinion plugins are the better solution and for sure a good documentation of all plugins like anchor Themes - could also host it on Github or at least creat a respo so everyone can fork and add their own plugins.

—

Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHub: https://github.com/anchorcms/anchor-cms/issues/210#issuecomment-16701026

[bsdlp]

Can we add better documentation for nginx rules?

Many of the top results from a quick google search result in incorrect community-sourced examples, and can obviously create a headache for new users.

[chromakey-io]

when you guys use the @ thing ... try and use the drop-down feature and choose from the list.

When you enter just the first name of the person you are responding to ... it doesn't reach them. It reaches some random person that registered just their first name as their username ... and bugs the shit out of them.

In this case, that was me.... good luck on the 1.0 release though. Looks neat.

[GiovanniK]

Is there a release date already? I am really waiting for it :+1:

[laurensdeb]

It'd be awesome if you would be able to add plugin repos/ host a repo yourself, like with sudo apt-get on ubuntu.

Laurens

[OzzyCzech]

What about use https://github.com/bower/bower for Plugin repository?

[daviddarnes]

Maybe a bit overkill?

[OzzyCzech]

Agree, it's overkill for regular user, but they still can download repos from git as zip file.

Advanced user can have bower.json in plugin dir and can easily get information about new versions can combine zip files resources and git repos resources. Can ignore all plugin sources in his private repo (because is somewhere else).

[Boztown]

This is great! I see "Drag-to-add media (drag a file to the screen, add/detect type)" is checked off. Does that mean it's being worked on? To me this is a pretty important feature to have. I got it working (basically) in my local copy and could work on it more and commit it but I'm concerned it's already been done and I'm missing something...

Oh.. and if I'm not being clear I'm referring to uploading images via the drag and drop.

[daviddarnes]

Not sure if this has been mentioned before, would be nice to have the ability to add custom fields in when a certain theme is enabled. Mentioned on the forums http://forums.anchorcms.com/discussion/auto-creating-custom-fields/1#post-1925

[yckart]

Any thoughts on managing media-files?

[emaleesoddy]

Any thoughts on managing media-files?

I'd rather not see it in the core, but it would be a nice plugin.

[GlennWolsey]

I'd love the possibility to save a post as a draft, and preview that post in a new window (with the post remaining private).

[yckart]

@GlennWolsey I think that is a nobrainer and already possible...

[daviddarnes]

@yckart I agree, however I think @GlennWolsey would like an actual preview button in the edit post area. Which isn't in Anchor as of yet.

[simoncla]

@yckart It is already possible as long as you know the slug and set the post as 'Draft' it's essentially a preview. Only issue with this is I believe that's all it is, as in as long as anyone knows the slug they can see the post so it's not completely private.

[adam-lynch]

About the image insertion (which is already done, right?), will the user have to create a custom field for every image they want to add to a post? I hope not.

@Simonclavey, it should really just return a 404 if the user isn't logged in as an admin.

P.S. Any tips on getting involved / contributing?

[ghost]

Nope, I believe it just adds the image to the content folder in the root of the anchor installation and then it gets required when the post is viewed.

[AminKAli]

Are there any specifications for how the plugin framework should be implemented? I wanted to work on it and wasn't sure if there were any design documents outlining desired attributes, functions and structure for the plugin feature or any of the proposed 1.0 Features....

[AminKAli]

The current implementation of Post Variables lives in the meta table. Are there plans to move this to a separate table? As a plugin generated Post Variable(think wordpress shortcodes) will likely not be used for site meta data, the options are to: 1) store plugin/non-meta variables in their own table. 2) simply move all the current entries to a more generically named table,(maybe a "variables" table?).

Which option do people prefer?