Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 01/26/2021 in all areas

  1. The Bard field in Statamic has been been discussed and mentioned several times in the forums, dating all the way back to 2018, as something worth emulating in ProcessWire. Here is a short demo of a proof of concept of an unimaginatively (temporarily?) named (and very colourful) module doing just that. Demo App running outside ProcessWire. Screenshot Screenshot of the app in InputfieldBrad, running in a modal, quirks and all. Way Forward I don't know but no current plans for any sort of release, paid or otherwise. I like where @flydev ?? is headed with FieldtypeEditorJs so let's support that ?.
    7 points
  2. Hey folks! Iam exited to show you a preview of a pagebuilder fieldtype I'm working on for quite some time now. Let me know what you think
    5 points
  3. If anyone else is interested, I started researching different ways to try to solve this problem(not just with Processwire.) You can view the Google doc here. Feel free to copy/edit or whatever. I wonder if we can simplify things? Do we really want a layout editor in the Processwire backend where you can adjust the grid widths and so on, or do we just need some UI modifications to the tools we already have? Here's an example where I think the backend page editor is too complex. from:https://getkirby.com/ and https://modmore.com/contentblocks/ The page editor could slow down and be clunky from trying to render all the DOM elements? Too complex to work on mobile Content editing gets smushed into small columns Dragging and dropping across layout regions requires a lot of dexterity for the end users - think accessibility. requires taking up the whole page for editing A page/layout editor will have to somehow visually represent your frontend layout in the backend. That seems problematic to me. Instead of having a complex page/layout editor where the user has to drag and drop columns, how about we simplify the interface so that it works on mobile as well? While the YooTheme demo looks cool, I don't think it would work good on mobile? I think the YooTheme UI is still too complex. How about we just allow the user to choose from prebuilt sections or components? Those prebuilt sections/components could then be edited in the Processwire sidebar panel like the Processwire ProDrafts sidebar editing. It would be cool if the RepeaterMatrix, Page Reference, Page Table, Repeater fields got rid of all the cluttered "Add New" type links and instead had one "Add new" button/link that would give the option to choose a template visually in a Processwire Sidebar Panel. Maybe also add another option to RepeaterMatrix, Page Reference, Page Table, Repeater fields to edit pages in the Processwire Sidebar Panel instead of the inline expand/dropdown editing? Just like the Processwire ProDrafts module does with Live Preview? This is how Godaddy.com's website builder works. You can try it for free. When you click the plus icon to add a new section, it shows this selector in the sidebar. This is also how https://froont.com/ sidebar works. A user selects a prebuilt section or component/widget. Also http://cards2.webflow.io/ and https://froala.com/design-blocks and https://www.brizy.io/brizy-design-kit-2/ you can see how a page is built from these widgets/components that stack on top of each other. Imagine if I were to create a Processwire "Landing Page" template. It would probably only have 3 fields: Page Header - Single Select - to override the default site header Page Sections - Allow Multi Select - to add layout rows Page Footer - Single Select - to override the default site footer That would give a lot flexibility of the page design without allowing a user to screw up the design. When looking at the processwire page editor, it could show the three fields each containing a preview graphic of the element that was selected. Maybe @bernhard 's module would allow the visual selection of the templates somehow or maybe @ryan could add a representative/template preview image option to all the templates? The Sections field would allow multiple selections. Those selections would display in a single column like the Page Table field that allows you to move the preview graphic of the element that was selected up or down in the list. Maybe Page Table Extended could be used to show that preview graphic from the TemplatePreviewImages module? I haven't tried. If you click the preview graphic, it will open that element in the Processwire Sidebar Panel for editing. Here is a rough mockup of what it could look like: That way the page editing is nice and simple, no need to worry about messing with the indentation of nested elements like in this example: Indentation is too easy for editors to mess up IMHO. Now what happens if you click on the "Three Column" item above? It would open for editing in Processwire Sidebar Panel on the right. Now that "Three Column" page has other Page Reference fields to components/widgets: Column 1 - contains a RTE Editor widget using a limited/restricted CKeditor or a markdown editor? Column 2 - contains an Art Directed Responsive Image widget Column 3 - contains a Accordion widget with other types of referenced widgets like a Editorjs.io widget or a file downloads listing widget So that is where I'm not clear on. Do we need some mechanism to allow us to "Drill down" to edit other referenced pages in the sidebar? How do we go deeper? Could there be some kind of breadcrumbs or back button like on an iphone? The SilverStripe CMS has drill down editing as seen in this video at the https://youtu.be/IKGUd2dq8XI?t=1022 although it doesn't use sidebar editing. Technically, I'm not sure how they achieve that? Anyways, I don't have the solution, but I thought I would share those concepts as rough as they are. ? I also like Bernhard's concept of defining these widget/components in code so they can be shared across sites. Creating all these fields and templates by clicking in the admin would not be fun. No disrespect to Processwire. (I love Processwire and it's admin theme btw) I love hearing all the discussion on this. It's one huge problem that definitely needs solving. I need to able to give non technical users the ability to create customized landing pages without them knowing html. They like to be able to switch out a whole section just to see what it would look like. That's why I would prefer to give them the ability to select prebuilt responsive components instead of allowing them the ability to create grids with rows with margins and paddings and so much other htmly stuff.
    3 points
  4. I think Hanna Code is not a good candidate for solving this need. For a couple of reasons: 1. The Hanna Code textformatter does not necessarily only execute once when are outputting the field value in your template. It executes whenever the formatted value of the field is accessed. In practice I think you'll find this happens (or can happen) more than once in the same request (Ryan has pointed this out somewhere, and you can test it with Tracy Debugger) and so your counter incrementation is not going to be reliable. 2. You will be using the exact same tag [[nextimage]] multiple times within the field value. The Hanna Code textformatter uses a str_replace() to replace all matching tags in the field value. So it doesn't matter how you increment a counter within the Hanna tag code - all identical tags will get the same replacement value. Instead I think you should use your own placeholder and then do your own replacement (either in a template file or in a custom textformatter module). Example... In your field value, use the text {{nextimage}} inside a paragraph by itself. So the resulting markup would be <p>{{nextimage}}</p>. In your template file you can use preg_replace_callback(): $body = $page->body; $images = $page->images; $pattern = '/<p>{{nextimage}}<\/p>/'; $count = 0; $callback = function($matches) use (&$count, $images) { $out = ''; $image = $images->eq($count); if($image) { $out = "<img src='$image->url' alt='$image->title' title='$image->title'>"; } $count++; return $out; }; $body = preg_replace_callback($pattern, $callback, $body);
    3 points
  5. Recently @Wanze starred a free app on Github, just awesome : https://github.com/responsively-org/responsively-app It's a browser modified that show how a website work in all selected devices. I think a lot of people will fall in love for this soft - give them a star on github ?
    2 points
  6. Thought I would release a pretty simple module I made that integrates the awesome OneLogin PHP SAML toolkit into ProcessWire so you can use SSO with your ProcessWire website. Mainly developed for my own purposes as I have used SAML plugins with WordPress for many years and now that ProcessWire is my go to CMS I sort of missed the convenience of having SSO between sites and services. This is my first attempt at a ProcessWire module, it's probably not the best in terms of code, but it has been pretty stable in my tests. Here's a little demonstration of the module in action https://www.youtube.com/watch?v=YWcsV6RTh90 GitHub repo and Installation Instructions https://github.com/adamxp12/ProcessWire-SAMLAuth Any feedback would be appreciated. Even though this is quite a niche module.
    2 points
  7. If your module has a lot of config fields you might want to divide them into groups inside a tabbed interface. Here is a demonstration module showing how this can be done. https://github.com/Toutouwai/ModuleConfigTabs Thanks to @kixe for providing my starting point in this forum topic.
    1 point
  8. And one more... Meet Brad, a proof-of-concept Bard Fieldtype ?.
    1 point
  9. Great job jploch and kongondo! Ya'll can really put together modules quickly. Looks like that could also be used as "Freeform layout builder" component/section that can be added to a normal page table like I show above? jploch, I wasn't clear on how the user gets to see the grid editor in your example video? Do they click on a button to enter into the grid editor or does it take over the normal page editor somehow? I also like the mobile preview buttons at the top? Maybe ProDrafts preview mode can add those? I think CraftCms just added that feature as well? I expected it would work like the ProDrafts preview mode's sidebar? I just don't want the preview area modifying the site's markup. Like adding plus icons everywhere or drag and drop. That is what the Godaddy.com editor does. I'm not a fan of that. Sometimes those *features* can cause CSS conflicts and cause the preview to mess up. See below for example of the buttons that appear on hover: I like how the ProDrafts preview mode doesn't add those *features* to the preview area. On another note...people here were also talking about Editorjs.io and storing content in json in the database. I ran across a spec for that from https://www.sanity.io/ it's called Portable Text https://github.com/portabletext/portabletext and they talk about it more here. I guess you can run into problems when creating headless sites that store rich text as HTML in the database? They use JSON instead to remove all the styling and so on. I'm not sure how widely it is used, but I thought I would mention it in case anyone hasn't heard about it. I'm also not sure if it is compatible with Editorjs.io?
    1 point
  10. You'll find nearly the same question (if I understand you correctly) and useful answers to get you started (I've just added one!) here: For SAML, you might want to start with this module: https://processwire.com/modules/saml-auth/. And there's a post about it:
    1 point
  11. There are a tons of ways to do what you're asking, so I'm just suggesting something based on your previous example. In the template add a repeater field "repeater" and add to it 3 fields (name whatever you want, just stick to mine if you want copy/paste the code block below): 1) class_string 2) title 3) description All of them are of type "text". Fill them as you like. In the template file then paste this code where you need them to be placed. <?php foreach($page->repeater as $block): ?> <div> <div class="box-pf"> <i class="<?= $block->class_string ?>"></i> <a href=""><span class="uk-text-middle"><i><?= $block->title ?></i> '<?= $block->description ?>'</span></b></a> </div> </div> <?php endforeach; ?>
    1 point
  12. There are a couple of blocks that I did not show. I can add another video to showcase those, when I find some time. In the meantime you can check out https://www.michael-philipp-bader.com/ to see them in the frontend. The home page (overview) for example features a gallery block that opens an image or video in a light box. On the contact page you can see a map block that uses the Leaflet Map Marker module. On the portfolio page there s a page reference block that loads all the selected pages/projects. I just want to be clear that it's up to the developer to create as many blocks as they like. Blocks can have all the fields that are available in PW. You just create a template and assign fields (like you normally do) and add that template to this fieldtype. Then you create a file with the name of that template in your template folder (or subfolder if you use the delegate template approach feature of this module) with the markup that gets rendered. You can also add a special class to elements you want to make draggable/resizable. More instructions on how to use this, with code examples will follow, once it's ready.
    1 point
  13. This is impressive and fulfills a lot of requirements I am looking for this type of page builder. I particularly like the use of blocks as pages (maintaining the PW flexibility to reference these blocks from other pages), that styles are saved separately in JSON and a stylesheet in generated for each page (which you can check in the source code of your example), and above all the use of CSS grids that allow much more complex and visually interesting layouts. I wouldn't let my clients touch this kind of interface unless they're design-savvy, so I'm glad that design features can be disabled for certain roles. Congrats!
    1 point
  14. Good writeup, thx @gmclelland ? Exactly what I thought, when I read your concept. I think the best solution would be to have the page editor work only on the frontend. Then editors have the final layout instantly visible on the right half of the screen and when they click on a block, they can edit that block in a sidebar on the left. If the block had a nested block, they could simply click on that block, which would open a new sidebar at the same position on the screen (left side), overlapping the old sidebar, then closing it. So the editor would be in the nested block and if he/she wanted to go back to the parent block, he/she could click either on "parent" (maybe having breadcrumbs, as you mentioned) or choose the block to edit from the right side of the screen (live preview). Well, that's exactly the concept @kongondo has shown in his video ?
    1 point
  15. Holy cow! This is freakin' awesome! Thanks @Wanze and @flydev ??
    1 point
  16. This is not a direct answer on the current problem, but shows a different method for using a custom var in different scopes: Instead of using a superglobal var it may also be possible to use ProcessWires Functions API with a custom var name. // initialize a custom var, maybe in your site/_init.php region('hannaCounter', 0); // later in your templates or modules or where ever, count up the counter region('hannaCounter', region('hannaCounter') + 1); // and where ever you need it, get the current (or final) counter value echo region('hannaCounter');
    1 point
  17. Hi @Marco Ro, The map uses LeafletJS with two layers, OS Maps (UK only) for the road map, and Mapbox for the satellite. For analytics, we're still experimenting with explicit consent. Matomo has a cookie-less option so theoretically we're able to record every site visit using it, but can only record those that have consented using GA. I really hope Google figure out a cookie-less analytics implementation soon, it is an absolute nuisance! Cheers, Chris
    1 point
  18. The HTML5 number input should handle that already. For formatting for output I'd suggest looking at NumberFormatter of php / the intl extension. Having worked with a cldr based library elsewhere extensively I can suggest everyone dealing with locales to use a library for all those differences instead of building one-of solutions.
    1 point
  19. Definitely ?. This was for demo purposes only. My plan is to develop my own using Affinity Designer...at least the easier ones. However, I don't know how much different I could make them look compared to YOOTheme's. Thanks. Will have a look. By the way, I have been keeping an eye on this one: https://heroicons.com/ ...by the folks at TailwindCSS
    1 point
  20. Nope ?. This is all handcrafted using Vue JS + TailwindCSS + custom JS + some drag and drop library. I sometimes use vanilla JS for drag and drop but didn't this time. I have never used grapejs. You are wrong in your assumption ?..., at least in the context of what I am developing here. We are managing content; we are just not using "traditional ProcessWire inputfield interfaces". The app runs in __render() method of the inputfield. Saving is via ajax but that can be changed to form submissions with page reload if one wanted to (not that I would want to do that myself). All my responses below are with respect to this Page Builder. Wrong again. Jessica White's data actually lives in the database. Still wrong. Jessica's marital (or any other of her attributes) status lives in the database. It is retrievable via the API and editable in the app GUI...all the CRUD goodies. You update it once and it is reflected everywhere that data is used, both live as you are editing and once you save your edits. That's what is happening in this builder as well. You can choose anything. Literally, anything from the system. It's just a matter of requesting it via the API and getting back a response from the server ?. It's not shown in my demo but you can even do Page Reference fields. All data requests by the App request are vetted on the ProcessWire side (permissions, validation, sanitising, etc). Neither have I but it looks like your brief experience with it wasn't great? Maybe it was a misconception? A quick Google search tells me grapejs can work with a database backend. We can and we do....? Examples include Padloper 2, this Page Builder and other Vue JS apps I have built (unreleased). By smart content I assume you mean data stored in the database, be it in ProcessWire fields or custom tables. All the data you see in the demo of this Page Builder are stored in ProcessWire tables (Fieldtypes). You can access this data using the API and carry out any CRUD task using the usual ProcessWire API.
    1 point
  21. Po delší pauze jsem dopřekládal, a opět můžete použít kompletní češtinu pro Processwire verze 3.0.165. https://github.com/PavelTajdus/ProcessWire-Czech-Language-Pack/releases EN: Czech Language Pack was updated again to PW version 3.0.165.
    1 point
  22. WOW! This is incredible! I think this idea really has legs and you've proven it can be done in a ProcessWire way. I would like to contribute in any way I can... ideas, styling, testing, financial. I would 100% use this on multiple projects if it could be developed further. I hope you are able to see this project through as well as Padloper. Please let me know how I can help.
    1 point
  23. Hi @thibaultvdb, thank you for reporting this issue! I'll be honest: In my Apis I actually always use arrays as return values, so I didn't notice this bug. With version 1.1.2, which I just released, you can use a stdclass again instead of an array as return value. I hope everything is running smoothly again with your Api? I would be very happy about a short feedback!
    1 point
  24. That doesn't work. The field visibility would only close the whole repeater field. Also repeaters aren't getting much attention lately as page tables are the defacto better alternative in most cases. There where lots of requests for automatically closed repeaters before page tables came along, but I'm not aware of any solutions.
    1 point
×
×
  • Create New...