lekoala / silverstripe-base Goto Github PK

A base module for my SilverStripe projects

PHP 75.95% JavaScript 7.80% Scheme 9.00% CSS 1.29% SCSS 5.96%

silverstripe-base's Introduction

SilverStripe 4 Base

By default, SilverStripe lack some really common stuff I find myself doing in most of my websites. This module aims to provides basic functionnalities that can be easily used on a website.

This module is under heavy work in progress, things breaks and will change. Use at your own risks.

Requirements

SilverStripe ^4.1
Use public folder

Installation

You can install this module with Composer:

composer require lekoala/silverstripe-base

If you install this as a git submodule don't forget to adjust your autoloader

"autoload": {
    "psr-4": {
        "App\\": "app/src/",
        "LeKoala\\Base\\": "src/",
        "LeKoala\\Base\\Test\\": "tests/"
    },
    "classmap": [
        "app/src/Page.php",
        "app/src/PageController.php"
    ]
},

Also you may need to adjust your default app/_config/mysite.yml to make sure base module is loaded first

---
Name: myproject
After:
- '#base-extensions'
---
SilverStripe\Core\Manifest\ModuleManifest:
    project: app
SilverStripe\Control\Email\Email:
    admin_email: [email protected]
# If you use bootstrap 4
SilverStripe\CMS\Model\SiteTree:
    extensions:
        - LeKoala\Base\Extensions\BootstrapPageExtension

This also applies to your theme.yml

---
Name: mytheme
After:
- '#base-theme'
---

Features

Common pages

Contact Page with Google Map support
FAQ Page
Simple News system (if you need a more complex solution, use the Blog module)

Extended DataObject actions

Now provided by lekoala/silverstripe-cms-actions

Themable sites

Make sites themable through the SiteConfig and offer support for variables in your css files.

See docs/Theming.md for documentation.

New or improved db field types

Need for country, color fields? Yes! Should your enums map labels to a static method? Yes! Should your scaffolding use better input fields? Sure! :-)

Forms

Lots of new form fields.

See docs/Forms.md for documentation.

Alerts

Define sessionMessage on your controller and display messages using Alertify library

Dev tools

Now provided by lekoala/silverstripe-devtoolkit

Maintainer

LeKoala - [email protected]

License

This module is licensed under the MIT license.

silverstripe-base's People

Contributors

Stargazers

Watchers

Forkers

restruct bergice michalkleiner

silverstripe-base's Issues

FilePondField show existing uploads?

Just a quick check: FilePondField is working very well both in back-end & front-end. The only thing which seems to be missing is the display of existing/previous uploaded files (like UploadField does).

Is the display of previous uploads not yet implemented? Or should this be working (and am I doing something wrong)?

FilePond seems to be able to do this (references):
pqina/filepond#13
https://pqina.nl/filepond/docs/patterns/api/filepond-object/#setting-initial-files

Wauw! Treasure trove, really...

I've been keeping a 'cms tweaks' module at hand myself but that's nothing compared to this gigantic collection of improvements. Going through the code in this module, I find a lot of usable stuff, thanks! For example we too often require just save & close, uploads in front-end, various form-related stuff, all great.

Just one remark; I'd like to use only certain parts in a framework-only project (right now mainly filepond, as per your recommendation). Currently this module requires a Page class & pulls in SiteConfig & some more. By default it creates various page types like block/news/contact/etc which is unwanted in this project. We also have our own basic news & FAQ modules, so that'd clash with this module currently. Plus I think 'save & close' is actually getting included into framework by default. Basically in its current state this module seems about 10 various 'Gridfield-enhancements' (all great) combined into one.

I'd like to kindly recommend to split up this module into 'domain-based' smaller modules, optionally with a composer recipe to pull them all in at once when needed (or just a regular composer package which requires all of them).

Domains could be like the headers in the README/namespaces:

upload-alternatives
dataobject-enhancements
admin-enhancements
modeladmin-enhancements
cms-contactpage
cms-faqpages
cms-newspages
cms-blockpages
themable-sites
subsite-enhancements
admin-alerts
social-extensions
ss-helpers
etc

We followed this route with our 'gridfield-pages' based modules in SS3, which consist of a reusable tagging (& categorizing) module, a Gridfield 'sitetree-button', exclude-children to hide pages from the sitetree & then some modules for specific purposes which pull them all in, like gridfieldpages, newsgrid, etc. For example the tagging & categorizing module can be re-used on its own which we do often. Also the excludechildren & sitetreebutton modules go installed a lot more than the actual newsgrid module, so apparently those provided some specific functionality usefull beyond the modules we developed them for.

Curious to hear what you think of this suggestion.

FilePond/front-end uploads: async uploads may pose security issue

It occurred to me that (especially in a front-end scenario) having a hidden field with just a file-id as a value poses a possible security issue as anyone could spoof the ID and attach/'upload' any (existing) file as his own.

I can think of two ways to prevent this;

storing uploaded file-IDs into the session & checking upon attaching
set the upload to be synchronous (upon form submit), so files get attached directly instead of via ID (not sure if this actually does prevent spoofing an ID though)

unable to install module using composer

Hi I don't know what caused this issue but I was only able to install this module using composer require lekoala/silverstripe-base if I added repositories array in composer.json