Grav-plugin-admin: Customization of date format

[mabushey]

I use a date format of YYYY-MM-DD. I would like to be able to configure grav so I can use this format in the item.md date line, and in the admin plugin interface admin -> options -> publishing -> date.

[jpfleury]

This format corresponds to the ISO 8601 standard for date. When I installed Grav, I looked the settings to see if I could select it.

[jpfleury]

Maybe users could be able to specify a custom format in _Admin / Configuration / System_? For example right now, _Short date format_ and _Long date format_ are set with a drop-down list. If it was instead a combo box, users could choose a default value or type a custom one.

For the record, Wordpress uses radio buttons:

[mabushey]

I set this in system/config/system.yml:

25 dateformat:
26 short: 'Y-M-D' # Short date format
27 long: 'Y-M-D g:ia' # Long date format

The site seems to work well and interprets the date correctly, however the admin module does not respect this setting and flips the year and day around when saved.

[mabushey]

Also, I set timezone: 'America/Los_Angeles', but I don't see where to specify that the system clock is UTC.

[mabushey]

I see default has been added. Thanks. :)

Here's what I changed:

   dateformat:
-    default:                           # The default date format Grav expects in the `date: ` field
-    short: 'jS M Y'                    # Short date format
-    long: 'F jS \a\t g:ia'             # Long date format
+    default: 'Y-M-D'                  # The default date format Grav expects in the `date: ` field
+    short: 'Y-M-D'                    # Short date format
+    long: 'Y-M-D g:ia'             # Long date format

The admin page still shows the wrong format. :(

[rhukster]

still working on admin side

[mabushey]

:) Thanks for your help.

[rhukster]

Admin plugin has some updates in develop branch so that it will save in the 'default' format if set. The GUI picker still displays in it's own format (limitation of the Kendo date picker really, as it doesn't support arbitrary formats), but it will let you pick, and save correctly.

[mabushey]

bin/gpm install admin does not seem to install the develop branch. What's the best way to update this?

Thanks for the amazing support and code changes! :)

[rhukster]

bin/gpm does support symlinking to GitHub clones of the develop branches. You will be prompted to use symlinks if you have the appropriate ~/.grav/config file in your home directory. Here's mine:

# Full path to github and bitbucket repos of grav bits
github_repos: /Users/rhuk/Projects/grav/
bitbucket_repos: /Users/rhuk/Projects/grav/

Basically I have my clones in there, cloned with the same name as the repos. If you clone admin, login, plugin, and form from the develop branches, then try bin/gpm again, you will get a choice to choose symlink:

BTW, this is documented here: http://learn.getgrav.org/advanced/grav-development#github-setup

[mabushey]

That page, grav-development#github-setup is not something that I can understood. First off the definition of docroot appears to be wrong, but then again I can't understand what it is trying to get at.

Lets use the definition of docroot here: https://docs.acquia.com/articles/docroot-definition :
the directory that contains Drupal's core code files is referred to as its docroot, or document root.

So, my config, which is pretty standard, is I have /var/www/html that contains the docroot folders, so /var/www/html/www.example.com is the docroot for www.example.com.

I git cloned the admin repo into /var/www/grav/grav-plugin-admin

I created a /root/.grav/config file that contains:

# Full path to github and bitbucket repos of grav bits
github_repos: /var/www/grav/
bitbucket_repos: /var/www/grav/

Nothing makes any sense from there. The docs are missing copying bin/gpm into /usr/local/bin or someplace so a site that doesn't yet have gpm can still be installed. If someone wants to help me with this I would be happy to rewrite (or help someone else correct) this page to actually make sense.

[mabushey]

BTW I love being able to have one copy on my machine and each site just symlinks to the common files and only contains the files unique for each site. I used to set up Mediawiki and Drupal 6 that way.

[mabushey]

If you clone admin, login, plugin, and form from the develop branches

I think you mean email, not plugin. Correct?

[mabushey]

OK, I have admin, login, email, and form plugins symlinked in via gpm. How do I change the default date format in admin? It's still '01-09-2015 14:55', not '2015-09-01 14:55'

[rhukster]

in your /user/config/system.yaml (or system configuration in admin)

set:

pages:
  dateformat:
    default: 'Y-m-d H:i'

If in admin it's here:

http://polydeon.com/skitch/Configuration___Grav2_1B98F868.png

Of course this assumes you have updated Grav to latest develop version too.

[rhukster]

Regarding cloning.. Don't clone into your webfoot, clone in to a folder in your home directory somewhere, then the .grav/config file should be configured with your home directory locations (as mine were), and then when you gpm/install it will create symlinks in your webroot to your clones.

Anyway, this is an advanced topic that is primarily used by the core team of developers to ensure we have clones in only one place, and multiple sites and setups with symlinks so it's easy to manage many grav installs with many uses of the plugins and we don't want to deal with them all over the place.

[mabushey]

user/config/system.yaml:

 20   dateformat:
 21     default: 'Y-m-d H:i'
 22     short: 'Y-m-d'
 23     long: 'Y-m-d g:ia'

The short and long display are not being picked up in admin/system, however changes made to default do show up in the web interface.

Nothing has any effect on the date box under publishing.

[mabushey]

multiple sites and setups with symlinks so it's easy to manage many grav installs with many uses of the plugins and we don't want to deal with them all over the place.

This is one of the reasons I want to migrate some Drupal 7 sites over. In my early days of Drupal I tried symlinking to not have multiple independent copies, but it wound up being too problematic and caused more problems than it solved.

Wow I just noticed the debug panel showing what templates were rendered, timeline, etc. I like it. :)

[rhukster]

The short/long date are for themes to use when rendering dates. Not many themes use them, but they are there for legacy reasons.

Th "default" format is used when you save a page. Like i said above, the limitations in the date jquery script we are using means in 'normal' mode, the date is going to be displayed this way, but when you save it will be saved in the format you have defined. You can see this in action by jumping to the 'expert' mode or looking in the .md file directly.

Also it won't puke on you if you have your dates stored in the format you have defined like it did before.

[mabushey]

from 01.blog/logo_designs/item.md:

  1 ---
  2 title: 'Logo designs'
  3 date: '2015-09-01 14:55'

admin/system shows page format as 'Y-m-d H:i'

Make change at /admin/pages/blog/logo_designs and hit save.

01.blog/logo_designs/item.md changes to:

  1 ---
  2 title: 'Logo designs'
  3 date: '01-09-2015 14:55'

[rhukster]

Working for me.. Probably you don't have some update. Just wait till the next release and it will be sorted.

[mabushey]

Sounds fair enough. :) Thanks for all your help.

[ulab]

One of the original suggestions by @jpfleury (https://github.com/getgrav/grav-plugin-admin/issues/135#issuecomment-137230882) has not been implemented yet, has it?

The dropdowns for long and short date format are too limited - which might be a reason for why they are not being used in templates. :)

In addition if I change either to a custom value in the config file, it gets overwritten by any change in the admin panel since the dropdown does not reflect that change and saves the default/first entry.

[mjmaax]

in your /user/config/system.yaml (or system configuration in admin)

set:

pages:
dateformat:
default: 'Y-m-d H:i'

This doesn't work for me. Any change from the admin panel overwrites the date of the markdown file ignoring the format set in system.yaml.

[foxfabi]

Adding custom dateformats in system/blueprints/config/system.yaml works for me

[rolbr]

@foxfabi Not sure whether these changes would survive the next update of Grav, the docs recommend creating a user/config/system.yaml file and modify settings there. Did you have success using that approach?

Also see https://discourse.getgrav.org/t/set-date-format-for-blog-posts-to-standard-american-mm-dd-yyyy/6612

[ricardo118]

changing anything outside of /user folder will get removed when grav updates