Dev Diary 86 - New Templates Features Revealed

I think my solution would be very similar to yours!

I’ll include some designed ready-to-go modals in the Core Pack, and these could easily be dropped into our form templates.

1 Like

This is a great feature!

Is it going to be possible to add PHP-files, CSS-files, JS-files etc. and hide those from users who will use/buy the devpack? Like with a Stack? Only expose the UI-elements?

Yes, you can add extra files to a Component in a Dev Pack, see the API docs here.

There’s a repository on GitHub with examples of how to include extra files in an Element Pack.

If you tell us exactly what you’re trying to do we can give more specific feedback about how you would accomplish this.

Hope that helps!

This is really amazing especially being able to add your own stuff you have made up already. Just one pedantic comment I love the idea of the “scafolding” but you missy an “F” out its “scaffolding” unless this a new category for ELEMENTS? :slight_smile: Also it has already been mentioned but I am now starting to lose my brain thread as each DEV Diary seems to add a new name for something else so as an OAP I’m starting to get a bit confused - but at my age thats easy! :slight_smile: WELL DONE can’t wait to get hands on this and CMS stuff.!

2 Likes

Amazing! Thank you!

1 Like

So… what other kind of list items would be useful in the core template pack?

Five commonly used types of lists:

  • Unordered Lists (bullet or icon): use when order of listed items is not important, allow icons with text for better visual hierarchy.
  • Ordered Lists (choice of numerical system, 1,2,3; a,b,c; i,ii,iii; etc. ) : use when order is important, such as steps in instructions
  • In-sentence Lists: use when you want to maintain sentence structure and paragraphing, and have a short list (2-4 items)
  • Labelled Lists: use when the listed items require some explanation or amplification.
  • Nested Lists: use when listed items have sub-lists (list within a list). Ideally at least 3 or 4-levels deep.
  • Inline Lists: Display items horizontally, often in navbars or tag groups.
  • Definition List: To present terms and their definitions or descriptions.
1 Like

I think most of those classic “inline text style lists” will be covered when we add support for lists to the typography plugin. :grinning_face:

I guess I was more asking for fancy types of items you might sometimes want to put in a list, a little like the download files list. :laughing:

Oh, and visual examples of what you’re after are always helpful.

Keep the feedback coming, it all helps!

Really fantastic work, Dan &co. This will be so useful.

Upon creation of a Pack, I would like to see presented to the creator a standardized (by you and the community) list of ‘tags’ that categorize what the Packs is/contains. That will make it easier to a) ‘shop’ for packs on the store and b) find components we want to use across our (assumed) vast collection of imported Packs. Much like what is done in Stacks. See my attached mock-up/Stacks reference.

1 Like

You can add tags in the info.json file.

Not sure yet if they will be only for the Elements Store or for use In-App as well. Currently they don’t return any search results.

I’m not sure I communicated correctly, but your suggestion means that tags are user-defined and subject to an individual’s spellings and categorizations. Therefore, since they lack that category/name/spelling standardization, they cannot be meaningfully searchable/surfaced even for the user themself. In my image above, for Stacks ‘Typography’ is a standardized Stacks tag given to the Stack by the developer. As a user, I am then able to just use the search function and find all Stacks having to do with 'Typography. As the number and types of Packs grow — whether our own, or those purchased/downloaded from the store — I just feel it imperative that some kind of similar standardized searchable mechanism be implemented.

(Separately, I don’t think sending new and regular users into .json files is the way to go for tagging/surfacing components. Just isn’t intuitive or user-friendly)

I have not yet been to your forum, can you link me to a list of the good apple compliant (for rapidweaver and Elements) internet hosts? Mine just started to charge me for email storage and I’d be happy to switch.

Thank you,

Rachel

Hi @clearstone

Check out team Realmac’s recommended website hoster below:

If you have any questions let us know.

Oh well, thanks. That’s who I am with.

I went to them as my old source did not understand how to work with your app. But now Chili wants to charge more for email storage and I’m used to having no limit.

Oh well,

Thanks,

R

way to expensive I use one.com get more for less and uf ever ive had a problem which are few and far between always a brilliant customer service. for one website that is.

And you use Realmac Software without issue?

both site created with elements on one.com

The pack itself doesn’t actually contain tags — it’s the components and templates inside it that would need to be tagged individually. So this wouldn’t really be the right place to add that feature, but I totally get where you’re coming from. Being able to tag or categorise your addons more easily would definitely be useful. I’ll chat with the rest of the team about it :slightly_smiling_face:

Sorry for mixing my terminology. Thanks, Ben, for getting and exploring the functionality I was alluding to.

Best,

Can I ask where/how you got your cookie opener? TIA