Leaderboard
Popular Content
Showing content with the highest reputation on 03/14/2023 in all areas
-
It's pretty straight forward. Instead of defining textual options, you create a page for every selectable option. Preferably, you group them under their own parent, and you'll usually want to assign them their own template, both to make queries easier and so you can add more fields to the template later. In your case, you can start with a (backend-)template "region", no need to add a PHP template file since the region pages are only for filling the dropdown. You'll also want a template "regions" for the regions' parent page. This one will be the overview page you're trying to build and therefore need a PHP template. In the first step, just create both templates with the minimum fields PW suggests (i.e. just a "title" field which will be the label in your dropdown). Then create the pages. Home - Regions - - Region 1 - - Region 2 - - ... In your hotel template, add a page reference field for the region, and on the "Input" tab in the field's configuration, go to "Selectable pages". Under "Templates", select "region". Edit your hotels and assign a region to each. Now you can easily iterate over all available regions in your regions.php template file, output the region's details and a list with the hotels for that region. A little PHP snippet as a starting point: <?php namespace ProcessWire; foreach($page->children() as $region) { echo "<h3>{$region->title}<h3>"; echo "<ul>"; $hotels = $pages->find("parent=/hotels/, region=$region"); foreach($hotels as $hotel) { echo "<li><a href='{$hotel->url}'>{$hotel->title}</a></li>"; } echo "</ul>"; }2 points
-
Hey, @wbmnfktr! Thanks for taking care of this project. Hope under your governance it will grow and thrive! I spotted some issues with responsive design. You get a horizontal scroll on some pages like this one. Take a look when you got time.1 point
-
Thx @Stefanowitsch fixed in v2.31.2 ?1 point
-
I included the script in my head like this: <? $rockfrontend->scripts() ->add($config->urls->templates . 'scripts/uikit/uikit.min.js') ->add($config->urls->templates . 'scripts/uikit/uikit-icons.min.js') ->add("/site/modules/RockFrontend/scripts/rf-scrollclass.js", "defer") ->minify(!$config->debug); ?> When minify is set to "true" this is rendered in the <head> section ("defer" missing):
1 point -
Great idea. This is the most flexible way of handling categories. Go for it ?1 point
-
If the first item isn't to be moved, it might be easiest to just add a fieldsetpage field containing the same fields as the repeater minus the select option.1 point
-
I found https://github.com/earldouglas/codedown which can be used to extract all code snippets programmatically from the markdown files. With Jekyll, code from gists can be embedded into markdown files: https://gist.github.com/benbalter/5555251 Couldn't find anything for 11ty, though. I browsed only through a few of the md files on https://github.com/webmanufaktur/processwire-recipes/tree/master/src/recipes and they looked quite uniform already. Haven't checked all of them, though. Are these all that exist? Everybody should have moved to PW 3.x already. How would you identify 2.x snippets? Most of the code from 2.x still works in 3.x. So I don't think that this destinction is necessary. As for the default standard. https://github.com/webmanufaktur/processwire-recipes/blob/master/src/pages/submit-recipe.md already is a good starting point. I don't think we need categories in addition to tags. Categorization can be done through tags in a flexible manner. Couldn't we also use tags for that, like "init", "ready", "hook"? EDIT: I just did that and made a PR.1 point
-
Thanks @David Karich, @nurkkaand @gebeer for the great insights and suggestions! Thanks for confirming. I now see how displaying all items from nested folders in the parent folder view can be problematic. I have been thinking of this (as a 'simple search') that is always visible and underneath that a link to click to reveal the 'advanced search'. This could either be a 'toned down' lister (e.g. some system settings not visible as clients perhaps don't use this) or a (configurable?) custom filter/lister that has only the most relevant features such as date, title, etc? Yes, can work this in. Either cookies, local storage or session. I agree about the need for compactness and even make this configurable. A visual to mockup to get more going would be great if you could show me one, thanks. Agreed. I am leaning toward how it is done in GDrive, with the 'view details' icon opening the details pane on the right. Yes, agreed. Good idea. Definitely agree. Tagging process should be as easy as possible for editors. In terms of the DB layer, I thought a bit about using the inbuilt image tags but now I am leaning toward saving these separately as 'categories', one per page. Although I am still thinking about this, one page per category has many advantages, including: Management: Managing all categories in one place: e.g., categories 'animal', 'dog', 'cat' are easier managed in one place rather than in image/file tags. Editors wouldn't have to know or worry about these pages. Their only interaction would be creating, managing (editing, deleting, etc.) categories. Editing: Edit once, edit everywhere: If we wanted to change 'dog' to 'Canis lupus familiaris' for instance, we can do it easily in one place just by editing the category 'dog' instead of updating image/file tags. Inputfield Control: Per template category control of available media (suggested by Nurrka) Using pages would make this implementation much easier, e.g. if people is a category, and an MM inputfield is limited (at template level) to only allow media in people category, we would only allow selection and storage of people children, i.e. categories 'men' and 'women', for instance. Category Tree: This will help with building the tree on the left. It is easier than to fish for tags saved in media. It is easier to work with what is referenced (the categories) instead of the 'referrer' (the media themselves) in this case. Nesting: It is also easier to nest categories (folders) if the are pages instead of image/file tags. Multilingual: Page titles (category titles) can be multilingual; image/file tags are not. Customisation: Pages allow one to scale as much as they need to. Say, in future, you want your categories to have a description or some other field, developers can easily add extra fields to the MM categories template. Agreed. In my thinking above, this would be a new 'Manage Categories' MM view. Predefined categories will force editors to only pick from these categories. We can perhaps use the details pane on the right (like GDrive) that I am thinking of as mentioned above for this. Editors could then apply categories to a selected media. Choices would be in a Selectize input. In this details pane, just like GDrive, if one media is selected, we show you its details, plus have the input for categories. If multiple media are selected, we don't show details, just manage/add categories input. I'll have a think about whether to retain the current MM bulk apply/remove 'tags'. Also, whether to retain this feature at all (i.e., the current 'tags'.) given that 'categories' are a more powerful feature (at least that's what I think). Thanks for the feedback. Maybe my suggestion for a 'simple' default search and an 'advanced' one would help with this issue? Good point, maybe even add a configurable threshold, e.g. if 20 or more items, grab first 20 then show text like '+ 150 more' or similar. Another great suggestion! We can make this configurable. No, the preview min/max are just for the upload (They are jQuery File Upload options).1 point
-
@wbmnfktr I checked our list and don't see your email is on it. So next I checked the list activity log and see that we got 3 bounces from your email about 2 years ago. After 3 bounces it removes you from the list, as Mailgun doesn't like it if we keep sending to an address that bounces. I think it can be solved just by re-subscribing. Please let me know if you find it doesn't. Thanks.1 point
-
v3.16.0 adds an xDebug launch.json file to the .vscode folder and a checkbox to control whether you want to use that feature or not. That means if you are using DDEV all you need to do to is to check the checkbox and then run "ddev xdebug on" Thx @dotnetic for the hint about xDebug on DDEV! I've just tried it today and it works great! compared to my last experience with xdebug on laragon where performance was really bad the performance on my ddev container is so good that I even forgot to turn it off today ? Page load times without xdebug: 100ms; with xdebug: 150ms ? And all that with zero-config!!! You have to try it ? See here how to use xdebug in vscode: https://www.youtube.com/watch?v=HrQWtbxY1Hs&t=331s1 point
-
Thank you, @gebeer for the awesome feedback. I love that idea! I wish we could create some sort of snippet collection (right now) from all of these recipes in some kind or another. While it would be quite easy for me to export each recipe to another format of almost any kind, almost each and every recipe has to follow some or all rules of formatting. Right now... the formatting is super basic but we can work on it and even could create snippets for only those recipes that support the wanted formatting. I could export those snippets, each and every time into another repository, when a recipe get's flagged as "isSnippet=true". If we can find a workable solution and formatting for real snippets... I'm here to support it! But first we should define a default/standard format for recipes and go from there. I wish we could go through all of the recipes to make them some kind of uniform, working with ProcessWire 2+, and mark those which only work with ProcessWire 3, or whatever version of ProcessWire, just to find a solid foundation. From there we could work out a snippet format and necessary fields, export them and even publish them to whereever we want. Something I forgot... there are snippets, ready.php snippets, common hook snippets... and probably more... so we have to classify snippets and recipes right from the start in some kind. But sure... that's possible. This will be fun! I really love this idea.1 point
-
@wbmnfktr Thank you so much for breathing life back into this project. Website already looks awesome. I have an idea/suggestion: it would be great if all the code snippets could easily be integrated and used in our IDE. With the current way of how they are stored on GH I wouldn't how this could be achieved. There is a vscode extension that lets you use gists as code snippets. So if the actual code snippets were organized in gists it would be possible to use those from within the IDE. Maybe there is an automated way of storing all snippets as gists from within your build process?1 point
-
Another short update: In the last few days @marcus and I talked and he made a member and owner of the "old" organization repo on Github so we can still use the old/former official repository - that's awesome! Yet... the old domain is long gone. I tried to contact the new owner but no chance so far. Even through buyback-services and domainer/s. Outlook: I will update all recipes to the new markdown format, while keeping a copy of the legacy version in a separate branch/version. I will update all guides on how to submit and update recipes in the next few days. AND: I bought the processwire.recipes domain - so I hope it was worth it. ? MORE (ideas and changes and whatsoever): Details will follow soon on processwire.recipes! In other news: Thanks @teppo for updating the link, I'll have to contact you again when the new domain and repo are online for the public. ?1 point
-
v2.19.0 comes with a new handy javascript snippet that can help, for example, to create to-top-links that slide in after a certain scroll position: If you have ideas for improvement let me know!1 point
