When setting the language of the user in Throwdown, subset context should be established when l18n is determined.

This will probably require one hell of a switch tree to set all possible subsets...

Throwdown requires a solid Introductory workflow explanation/guide.

http://www.sitepoint.com/list-files-and-directories-with-php/

Overall seems like a better implementation than a raw glob() setup... will look further into and see how things work with this setup.

Really digging http://surge.sh/ as a goto option, but we need some basic support for standard FTP uploads as well.

Articles should have the ability to be tagged. Planning to leverage this via FrontMatter.

Users should be able to search for article content. Should have the ability to filter search results via tags or categories or something...

Encompasses #19 #20 #5

There needs to a be a delimiter settings that defines what the root path for the system should be.

• The root path should be defined by the config.php file and stored in the global ROOT_PATH definition.
• If config.json doesn't define a "root_dir" property, then the value of "root_dir" is false.

This root path is removed from the URL string before index.php parses out the $requestURL array. This way $requestURL[1] will remain consistent across installs.

In regards to #15, we should move /themes into the content folder.

This overall cleans up the root directory even further and provides a more contextual barrier to any potential reverse directory hacks by plugins and themes.

figure out how to make /articles work.

some sort of /tagged mechanism for taxonomy creation and search indexing

Win XP, wamp local server at throwdowncms.loc. Composer installs all dependencies OK. Accessing it at throwdowncms.loc gives out :
Parse error: syntax error, unexpected '->' (T_OBJECT_OPERATOR) in E:__misccms2\throwdowncms\app\config.php on line 36

Thanks

Petros

Article categories are derived from the actual folder structure of your /content/articles/ directory.

If you place an article within a subdirectory of /articles then that sub directory is now a category. This makes managing cats and article meta EXTREMELY simple.

http://filp.github.io/whoops/
http://net.tutsplus.com/tutorials/php/whoops-php-errors-for-cool-kids/

Users deserve better error outputting and so do I.

Need to add specific validation methods for certain fields.

• Blog and User Names
• User Email
• Local/Remote host URL'

They're unnecessary since this repos' Issues page is doing a fine job of defining and tracking features and their development.

The user deserves some sort of admin functionality for managing trivial things like editing the main navigation.

Got a couple Ideas in mind on how to brand this thing. It's gonna be pretty sweet :)

In regards to #23:
These plugins could be included at the template level as I previously desired, by defining a directive block that specifies a plugin to be loaded.

https://gist.github.com/DrPheltRight/850106

https://getcomposer.org/doc/04-schema.md#type

To help curb potential spaghetti code situations, maybe we should consider setting up a template class that has a number of helper methods involved to extend the Mustache object's functionality.

This would allow theme creators to leverage an already capable templating system (ie Mustache) and developers could then extend that functionality via plugins.

PHP should assign a header("Location: $site_url/404"); redirect when a 404 conditional is met. This works around the whole "404" template generation by using a proper 404 signal from the server and avoids wierd conflicts with the template logic.

Need to modify page_404() to reflect this issue.

I want the ability to define a template name to be used explicitly with a given article.

Similar to how Trent Walton does his thing http://trentwalton.com/

In regards to #15 and #16:

Can we block plugins and themes from reversing (../..) into parent directories and scope child folder access only?

published: designates a given/future publish date for an article if specified. Otherwise, the system defaults to the physical files' modtime value.

Browser should not be able to access any configuration level .json files by default. This is a security measure that needs to be addressed at the server level via .hataccess.

Write:

[[ figure | src: image/path/here.png | alt: describe image contents | caption: contextualized info about the image ]]

Get:

<figure>
<img src="image/path/here.png" alt="describe image contents">
<figcaption>Contextualized info about the image</figcaption>
</figure>

Option(s):

• Let users write markdown in caption field
• Let users pass custom classes to figure element?

Has been implemented already, however needs to add a check if the minified file exists in order to default back to the non-minified source file.

http://us.php.net/manual/en/function.glob.php

glob() provides better handling of selecting specific file types using regex.

Due to #9, need to consider how plugins will be used. If user defines an asset that should be loaded by the plugin, an HTTP request to that asset will be blocked by this condition.

Maybe plugins should be defined inside of the /content folder.

https://github.com/HumanWorks/phpUserClass

seems sufficient for what I want to do...

1. How does this affect the current render pipeline for the system?

http://www.smashingmagazine.com/2014/07/01/server-side-device-detection-with-javascript/

I don't care for Disqus, but I'll document that one as well... I'd just like to offer people a simple solution for hosting your own comments :)

https://github.com/jacobwb/hashover-next

Need a method to generate the sitemap.xml file.

• XML Sitemap Guidelines - http://www.sitemaps.org/protocol.html
• Need a way to specify priority - global config.php setting per content type (page, article, etc)
• Consider using underscore.php - http://brianhaveri.github.io/Underscore.php/

Need way to clear elements using a clearfix element. It's a convenient shortcut though it's not a best practice.

Implement wordpress style shortcodes for allowing custom content injection without requiring specific HTML markup...

Likely needs some sort of plugin architecture to support this.

Browsers should not be able to directly access ANY file within the /app directory...

Throwdown\Plugin\... should be used by all plugins so it's scoped properly and autoloaded accordingly via Composer.