We are looking at adding some new default fields for pages.
We want to still keep it simple tho.
Focus is on SEO and useful publication and sorting/filtering capabilities.
We are looking at the much requested publication dates and might as well add them all.
Create Date
Modified Date
Publish Date
Un-Publish Date
I am suggesting a few more.
Long Title
Themes can choose to use this or title depending on where. Title can be used for page titles and other SEO, long title can be used on pages or more descript titles of the page.
Summary
Like description but for public display, can also be used for custom excerpts.
I was using those title fields with customfields plug (see attached img).
I'd go with additional:
- page intro image;
- author field (display name field from settings page); might be a dropdown allowing to choose who created/edited the page if there's more than 1 GS account, or not showing author at all;
- checkbox: do not add this page to sitemap.xml;
While creating multiple menus using i18n_nav, where some pages needs to be placeholders and work as parents, they shouldn't get into sitemap. I can't set them as private, as their slugs won't be shown in some cases.
- external link input field; currently available methods require programming knowledge
- menu item icon/img; I'm not 100% convinced to allow images in menu item, as it will lead to problems with proper positioning of those images. Eventually this option would embed css into li/a element with img as background url, and vertically centerize it;
some users asked how to do it couple times, but since CMS is for normal people, not for programmers, then why not ?
Addons: blue business theme, Online Visitors, Notepad
I think making fake pages is the wrong solution for menu placeholders.
Author field is not something we would consider yet until we have a core multi user functionality. It is internally tracked already, and we can add functions to alias display names in pagecache.
Menu item icon image is too specific, I would consider adding menu item link attributes, maybe an id or class.
What is page intro image used for ?
What is external link input field ?
2013-03-21, 02:21:42 (This post was last modified: 2013-03-21, 02:29:05 by yojoe.)
(2013-03-21, 01:53:52)shawn_a Wrote: I think making fake pages is the wrong solution for menu placeholders.
There's no better, and easy to manage solution.
(2013-03-21, 01:53:52)shawn_a Wrote: Author field is not something we would consider yet until we have a core multi user functionality. It is internally tracked already, and we can add functions to alias display names in pagecache.
It might be as well a checkbox: show author below page content.
Along with input field to override only one existing account user label.
Showing author has been requested at least twice.
(2013-03-21, 01:53:52)shawn_a Wrote: Menu item icon image is too specific, I would consider adding menu item link attributes, maybe an id or class.
I'm not familiar with GS menu generation function for long time, but Mvlcek's i18n plugin adds classes to menu items, taken from their page names.
This way stylizing menu items is possible with css, but it still requires basic css knowledge.
(2013-03-21, 01:53:52)shawn_a Wrote: What is page intro image used for ?
Article thumbnail is some sort of basic feature on blogs, and in news systems. Customfield with image allowed me to add quickly such functionality into pages, and create a simple news system based on search plugin (before special pages were developed by Mvlcek).
A sidenote: page thumb feature isn't as simple as it sounds, as images needs to be further processed and properly formatted before they will be shown in article. That's not a must have, just my proposal for future. If GS ever gets a native news/blog functionality.
(2013-03-21, 01:53:52)shawn_a Wrote: What is external link input field ?
Adding an external link in menu has been requested dozen times.
My solution to add external link into menu was to use header('Location.. in template, and feed it with link taken from custom field.
That's how external links are being managed in most of CMS, by choosing menu type, and pasting a link to external page in input field.
Of course handling such functionality using php redirection isn't the way to go, but looking at GS multiple menus solution with pages as placeholders: there's no other quick and simple to manage way for end user I could come up with.
Almost all things I've mentioned were already requested, some of them long time ago.
Nothing which can't be add into GS this or other way, but w/o basic php/css knowledge it's unavailable for non-tech users.
edit:
btw. Shawn, stop looking at things from programmer's point of view, and start looking from a non-tech, end user. Tons of things easy to understand, create, add manage etc. for you, is pretty often too hard to understand by normal people, who hear gibberish when you say "hosting/browser/domain/cache/login". etc.
Get ... simple
Addons: blue business theme, Online Visitors, Notepad
IMO any non-essential new field should be optional.
There should be a way to disable it (*) if you don't need it (or don't want the editor-user to touch it).
(*) via gsconfig, settings, or maybe a -bundled- plugin for each one that can be deactivated/removed.
@yojoe
This is a bit offtopic, but...
I don't see GS as a CMS for "normal" people, it's not so easy (though it's simple). It's for webmaster/designers that don't have to know php (they just need to know what tags they have to add/change/etc, like with WordPress but easier), people that make sites to be used by "normal" people.
Non-tech people that want to do sites themselves should use Blogger, Google Sites, WP.com or similar solutions.
This is all off topic, I am looking for field input.
I am fully aware of requested features and how UI complexity works and how to accommodate advanced features without hindering simplicity. And how to properly engineer solutions without kludgy hacks.
Carlos: good point. An array in gsconfig with field = TRUE/FALSE, would do the thing.
offtop: I was talking about features for users who manage content of websites created by webdeveopers&webdesigners. About owners of those small pages crated by someone else.
It's not a miracle that people started to love GS and use it instead of well known and popular apps like joomla, wp, drupal, cmsms. Think about the reason.
But this thread goes too much offline.
I came up with my proposals along with their example use cases.
There was one more thing I needed to do in <head> section depending on page, but can't remind what for did I need it.
Addons: blue business theme, Online Visitors, Notepad
I love the idea of a Summary for a public display.
I would like to use summaries of certain pages to build the home page.
When we create a page, have a checkbox that can say that we will use summaries to bluid the home page.
Français et éternel débutant
French and eternal beginner
2013-05-18, 17:06:24 (This post was last modified: 2013-05-18, 17:18:15 by Angryboy.)
With some of these fields, could they be populated using the fields from one's I18N installation if it is installed? I mean it already comes with CreDate for the creation date, so it seems unnecessary to have to create a separate XML node called CreateDate (unless I've misinterpretted).
Also, it would be helpful for those fields to have input datetime-local selectors for them to be modified on the page more easily. That was the main issue with the current date formats -- that you had to edit the XML file directly to fix those dates or use a plugin to do so.
Functions? I say that CustomFields and I18N's Custom/Special Fields went the right direction of just having one general function to call the field and modifying the parameter to the name of the field. So (like the caching functions):
So for the summary you could set $field to 'summary', $isHTML to true, $isDate to false and $isExcerpt to 0 or false. For the creation date, set $field to 'Cre(ate)Date',, $isHTML to false, $isDate to the format of the date that you want and $isExcerpt to null or 0. By default $isHTML, $isDate and $IsExcerpt should be set to null.
...is there a need to modify the names of the current fields? Like changing pubDate to modDate? (or is that the name of the function to call it?) Seems a little arbitrary in either case.
Regardless, just be careful that you aren't adding a lot of option fields whose job would be done by existing plugins. If the CMS is advertised as having 'everything you need and nothing that you don't', then there isn't a problem with having the functionality there as a plugin - just ensure that it is promoted enough for most people to find easily (e.g. when a user freshly installs GetSimple, it might be an idea to inform them of some helpful plugins to install off the bat (maybe in the confirmation email?), along with a brief explanation of how Extend works rather than adding those features to the core).
But I love the tabbed interface you guys have going on there. Definitely looking forward to seeing that in the next update.
@shawn_a: Please just store these new fields straight forward, no add_slashes, etc.
In a CDATA you don't have to do anything and if you don't use a CDATA, just add the field value as htmlspecialchars($value). In both cases the value can then be read by
Code:
$value = (string) $xml->fieldname
instead of trying to remember whether the value needs strip_slashes, htmlspecialchars_decode or what else.
Here's an example verifying this:
Code:
<?php
class SimpleXMLExtended extends SimpleXMLElement{
public function addCData($cdata_text){
$node= dom_import_simplexml($this);
$no = $node->ownerDocument;
$node->appendChild($no->createCDATASection($cdata_text));
}
}
$value = '<p>That\'s a test where "a" is < "b" & nothing else. <[[1]]></p>';
$file = dirname(__FILE__)."/test.xml";
$xml = new SimpleXMLExtended('<?xml version="1.0" encoding="UTF-8"?><items></items>');
$xml->addChild('a', htmlspecialchars($value));
$xml->addChild('b')->addCData($value);
$xml->asXML($file);
I was trying to keep it standard but I agree, i do not know why some fields are addslashed, before we extended simplexml perhaps? Last I checked everything is CDATA which is probably also wrong but works fine, just makes manual edits harder.
date formats will be stored as standard dates or unixtime, that is why getters is needed, for locale conversion depending on template output etc.
pubdate IS moddate. Which is wrongly named, I can reuse credate, but why does it have to be so short and confusing, and it might be incompatible with what we decide to use. Ideally custom fields should be partitioned in the file from native fields.