Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 07/18/2022 in all areas

  1. I like repeaters for structuring data. For building a layout, not so much. I've seen the demo's on this forum of people using repeaters in creative ways to build a layout, but it never looks very intuitive to me. I've grown to dislike this approach so I've been looking at other content management systems for inspiration. Bolt CMS uses Article Editor, which is a nice (paid) javascript solution that's basically an advanced wysiwyg editor with support for grids and other nice features. I decided to integrate this into Processwire as an inputfield. Here's a demo: I created a few plugins for Article Editor that take care of uploaded images, inserting links and Hanna code support for adding dynamic bits to the editor. And the field also works in repeaters. You can pass your CSS to the editor so that the editor preview should look identical to the real page. I am using Bootstrap. A bonus of building a page this way is that the whole layout is stored in a single field so there should be fewer requests to the database compared to repeaters. Please note that since Article Editor is not free, you need a license to use it. I've been working on this module on and off for a while. There are refinements to be made, like perhaps loading the Hanna code previews dynamically (they are currently inserted into the editor after saving the page). Not sure if it would be good enough to release publicly but I thought I'd share it anyway because I'd like to hear if you think this is a nice approach :)
    7 points
  2. Article looks great, but their licensing model is indeed problematic. Folks at Bolt likely got a custom license (or perhaps paid OEM license) to use it, but on what terms is hard to say — I couldn't find specifics about their licensing terms. Only thing they do say is that it's available for use "in Bolt itself", which is a bit vague. It's up to Ryan whether he finds this interesting enough to contact Imperavi and query about license ? Either way, I wouldn't count CKEditor 5 out of the race quite yet. To me personally it looks UI/UX wise like a solid upgrade over CKEditor 4. I do remember that it seemed potentially "too different", and there were some relatively basic features (which I can't for the life of me remember anymore) from v4 that the devs originally said would be very difficult or nearly impossible to implement in v5, but that was a long time ago so perhaps things have changed. First of all, CKEditor 4 being EOL'd in 2023 is a huge reason to move on. There's no guarantee of updates after the EOL date, which includes potential security updates. ProcessWire is relatively safe since most of the time CKEditor is used by trusted users, but there are cases where that isn't necessarily true. And even if it was, there could still be vulnerabilities that third parties can abuse. In my opinion it's painfully obvious that we must drop CKEditor 4 support from the core at some point in the future. If some prefer to keep using EOL'd software (which I would personally recommend against), there's always the possibility of stripping it from the core and converting into a separate, possibly community-supported module. For me personally CKEditor 5 seems like a logical next step, but admittedly I've not used it enough to know if it's really going to be feasible, let alone how much work it will require. It's a good idea to check out what else there is, but CKEditor has quite a few things going for it as well: plenty of features, solid UI/UX, longevity of the project, active community, being open source with no costs or limiting licensing rules, etc. As for ease of use, I absolutely agree that this is vital. And in this regard CKEditor 5 feels like a big step up — if anything it feels less confusing and more streamlined than earlier versions. I would not expect my/our clients to have any trouble with it. Give it a try and see for yourself, and do keep in mind that CKEditor 5 is configurable: features you don't need can be disabled ? Just my two cents. 100%.
    4 points
  3. This has attractions. But it would require PW to update the file path every time the page was moved or renamed - there would be other complications too - e.g. including an image in a RTE field in another page would mean that the html would need to be updated when the host page is moved/renamed. It might be possible to test out the idea using hooks, but my guess is that it would cause more problems than it solves. The method I use in DbMigrate is to do all the referencing in the generation of the migration using the path/name rather than the id and then using that to get the corrrect id for the files. For RTE fields, an id map is maintained $idMapArray[$page->meta('origId')] = $page->id; so that the html can be changed. This only needs to be done for a migration, not every time a page gets moved. So I think, on balance, my vote is to keep the id-based naming.
    3 points
  4. If content is created in both dev and prod concurrently and meant to be merged then you're essentially maintaining a distributed system. There's a lot of knowledge around on how to deal with them, but all that doesn't make it a simpler problem and not having conflicts (or resolving them automatically) remains to be a hard problem. That's why the migrations module I created ages ago used migrations to captured the intent for change instead of trying to merge observed changes after the fact – the latter either comes with a lot of caveats or is impossible. The simplest solution for the specific problem discussed is the suggestion of @wbmnfktr. Use two separate systems for files created in dev and pushed to prod vs. the system for files created in prod, that way there cannot be conflicts in the first place.
    3 points
  5. InputfieldHCaptcha 2.0.0 Version 2.0.0 of InputfieldHCaptcha is now available. Feature: Add a permission to bypass hCaptcha completely. See the documentation for details. If you're upgrading from an earlier version of the module, you may need to add the permission manually. Go to Access -> Permissions -> Add new and add a permission with the name bypass-hcaptcha. Breaking change: After updating, superuser accounts won't see the hCaptcha widget anymore and be allowed to bypass it everywhere. This is a potential breaking change, but mostly relevant to know for development and debugging purposes – make sure to test your forms in a private browser window. --------------------------- @Pete I've gone ahead and released the bypass permission feature in version 2.0.0. Let me know if anything is not working right for you!
    3 points
  6. This week on the dev branch are several updates to the comments system including support for custom fields on comments (which we're calling comment meta data). I'm currently working on a site that uses a reviews system powered by BazaarVoice. It's pretty nice but it's also very expensive (I think at least $500/month in this case). The system powers their reviews which include not just a rating and review text, but also a bunch of other criteria that the user can provide. See an example here — click the "Reviews" tab and what you see there now is currently coming from BazaarVoice. But in a couple of weeks you should see the same thing powered by ProcessWire. Think of this like a comments system with custom fields. That's not something that ProcessWire has supported before, but now this week it does. Though I know most don't need this, so have kept it pretty simple, focusing just on adding API methods to make it possible to get and set custom field values for any comment. These include: $comment->getMeta('name'); $comment->setMeta('name', $value); $comment->removeMeta('name'); The name and $value can be whatever you decide. There's also a bonus $comment->meta() method which combines the methods, letting you get or set, kind of like the meta() method on Page objects. If you want to use comment meta data like this, it's exclusively an API feature. So if you are looking to collect custom fields from users, you'll want to implement your own comment form rather than the default. In our case, we'll be using FormBuilder to implement the comment form that includes the review and custom fields. But you could just as easily use a homegrown form. When it comes to outputting that custom data, you'll want to handle it more like you would outputting a repeater, iterating through the $page->comments and then using $comment->getMeta('name'); for each of the custom properties you want to output. Worth noting is that output formatting doesn't come into play here, so if some text in the meta data needs to be entity encoded for output (for example) then that's your responsibility. How about later editing of the meta data? Should you need it, the ProcessCommentsManager module (Setup > Comments) has been upgraded to support editing of comment meta data. Next to each comment is now a "Meta" link, and if you click it, you'll get a modal window on top of the comment enabling you to edit the meta data as JSON. That might seem a little unconventional, but I'm trying to keep it simple and flexible. Most will probably use this to view meta data rather than edit it, but the ability is there when/if needed. I didn't think it would be worth spending the significant time building a full-blown page-editor like environment for editing comment meta data, but also felt like I needed something like this for occasional editing needs. The InputfieldCommentsAdmin module was also updated to have meta data links for each comment. But the reality is if you have ProcessCommentsManager installed, chances are you aren't editing comments in the page editor anyway. So a new option has been added in the comments field configuration (Input tab) enabling you to disable comments in the page editor and instead link to the editor in the comments manager. When enabled, your Comments field in the page editor would instead look like this: This is worthwhile because the comments manager is just a better place to view/edit comments in the admin since it is paginated, supports editing of all properties, and lets you sort/filter as you see fit. Whereas a big list of comments in the page editor just slows it down. This week the CKEditor version has been upgraded to 4.19.0 (see release notes). I'm also emailing with the people at CKEditor about getting us a license to use CKEditor 5 with ProcessWire. As you may or may not know, the CKEditor 5 license (LGPL) isn't compatible with ProcessWire's license (MPL2 and MIT), so we are working on a license agreement to make it possible. Since CKEditor 4 will reach EOL in 2023 it's a good time to start planning for CKEditor 5 and I'm excited to work with it. Thanks for reading and have a great weekend!
    2 points
  7. Is it really necessary to have CKEditor 5 in Processwire ? Is CKEditor 4.x not more than safe and powerful enough already ? CKEditor 5 will not make more productive neither make a website client more happy. It will only make things more bloated. At least leave the option with the user and client to choose CKEditor 4.x or another simple Editor for the client. Most clients are non-tech people occupied with business for whom something like CKEditor 4.x is already complicated. They will never use all its options anyway. All they need is to change some prices, text and pictures. So please leave the option for the client to choose a simple Editor. What made Processwire stand out from the crowd was its focus on a versatile and powerful api with a core free from bloat. How much of that is still true ?
    2 points
  8. Even though I never ran into this issue, I'd support something like: /assets/files/path/to/my/page/whatever-image.jpg Which could be used in one or another way, even outside of ProcessWire.
    2 points
  9. This module allows you to integrate hCaptcha bot / spam protection into ProcessWire forms. hCaptcha is a great alternative to Google ReCaptcha, especially if you are in the EU and need to comply with privacy regulations. The development of this module is sponsored by schwarzdesign. The module is built as an Inputfield, allowing you to integrate it into any ProcessWire form you want. It's primarily intended for frontend forms and can be added to Form Builder forms for automatic spam protection. There's a step-by-step guide for adding the hCaptcha widget to Form Builder forms in the README, as well as instructions for API usage. Features Inputfield that displays an hCaptcha widget in ProcessWire forms. The inputfield verifies the hCaptcha response upon submission, and adds a field error if it is invalid. All hCaptcha configuration options for the widget (theme, display size etc) can be changed through the inputfield configuration, as well as programmatically. hCaptcha script options can be changed through a hook. Error messages can be translated through ProcessWire's site translations. hCaptcha secret keys and site-keys can be set for each individual inputfield or globally in your config.php. Error codes and failures are logged to help you find configuration errors. Please check the README for setup instructions. Links Github Repository and documentation InputfieldHCaptcha in the module directory Screenshots (configuration) Screenshots (hCaptcha widget)
    1 point
  10. 1 point
  11. I have no idea if it will work – module config fields can't use a database table, they have to be able to store in JSON, so it would take some research and experimentation to see if it is even possible to use this field type in a module config. So setting schemaClass would have no effect. Most module configs that use repeatable interfaces are done with custom javascript, as far as I have seen. (For example use a text field for the first one, and then a hidden field to store the repeatable values; use JS to allow the users to add an inputfield, and then join all of the values together in pipe delimited hidden field..)
    1 point
  12. I would rather see CKE4 being replaced with https://easy-markdown-editor.tk/ as I and my clients really don't like the complexity of CKE4, and CKE5 is even more complex than version 4. I know that Easy MarkDown Editor is not as WYSIWYG as CKEditor but I could never set up CKEditor to be a true WYSIWYG editor anyway. Maybe it just my fault, I don't know. Anyway, at least Easy MarkDown Editor could be added to the core as an additional option. So in the end there would be CKEditor 5 and Easy MarkDown Editor, both being integrated as much as possible.
    1 point
  13. Thank you - I had Covid last week so haven't had time to look at this yet but looking forward to testing it out this week.
    1 point
  14. That one seems to have a paid license, which is probably a showstopper for having it inside the core.
    1 point
  15. I'm not sure how this would be implemented. "Universal" implies it would be independent of the environment, but if a new page (and associated files) is created in the dev env, how can you create a universal id that you know will be unique in the production environment (unless the dev environment has knowledge of the production environment which, in PW, it does not). I came across this problem in developing ProcessDbMigrate. If you use that to migrate pages, rather than the standard export/import, then hopefully it will resolve the ids correctly. See https://metatunes.github.io/DbMigrate/help.html#field-types. NB: If you do use my module, please take care to take backups of both environments before installation and before any migrations - it is still very much 'alpha'!
    1 point
  16. As far as I know CKEditor 5 is quite a different beast and transition to it would require some massive changes. But it surely could bring a lot to the table. Maybe even some basic content builder functionality.
    1 point
  17. No worries, this is always an interesting topic to discuss, as off-topic as it may be. My answer will be a bit lengthy, so I'll wrap it in a spoiler tag (feels overkill to split this into new topic) ?
    1 point
  18. when you do the code to add it, you would need to specify the Fieldtype to multiply, so that needs to be one of the options, 'fieldtypeClass': 'FieldtypeText' in the json or wherever... (haven't tested this, but looking at the module, it does need the "fieldtype to multiply" to be expressly set)
    1 point
  19. Just to be clear: CKEditor 5 is licensed under GPL, unless I'm mistaken. LGPL would likely be less of an issue (if not a non-issue), since it's relatively permissive (no strong copyleft, dynamic linking with proprietary code allowed, etc.) Anywho — very interesting to hear that there's a (likely) roadmap to 5 in the future ?
    1 point
  20. Thank you about the information! Can you please tell whether it is possible to use ProField: Multiplier for this module? I'm getting an error "ProcessSettingsFactory: Fieldtype is not set".
    1 point
  21. Generally speaking I second what Bernhard said above. Custom tables are rarely a good idea — though there are some exceptions ? Now, as for your error: As the error states, the problem is not that you don't have access to $database — that part works just fine. The issue is that in this case $database does not provide a method called "getIndexes". This method was added in ProcessWire 3.0.182, so the first thing to check is your ProcessWire version. If it's earlier than 3.0.182, this error is expected. If it's a later one, then we can continue debugging from there. Also, as a loosely related note, the use of getIndexes() seems a bit odd here. Usually one would use $database->getColumns() (which, just for the record, was added in ProcessWire 3.0.180) to display column names/labels ?
    1 point
  22. Do you really want to create a custom DB table? You can do that if you want/need to do it, but usually working with PW pages and the PW API is a lot more convenient. The API is easier to develop and use and also you get the benefit of a GUI for editing your data. Instead of creating a table in the DB I'd suggest you create two templates: orders, order Then you set the family settings of orders and order so that order is the only allowed child of orders and orders is the only allowed parent for order. Then you add fields to your "order" template: product (page reference field), customer_name (text), customer_address (textarea), customer_email (email) You don't need order_date, because PW stores the created timestamp of every page that you can use for that. Then you create your table with PW API: <?php $out = "<table>"; $orders = $this->wire->pages->find("template=order, limit=20"); foreach($orders as $order) { $out .= "<tr><td>$order</td><td>{$order->customer_name}</td></tr>"; } $out .= "</table>"; You can also use MarkupAdminDataTable but I don't know the correct syntax by heart ? Pagination can be tricky... Adding pages would be like this: <?php $p = new Page(); $p->template = 'order'; $p->parent = $pages->get("/orders"); $p->title = 'order XY'; $p->product = $yourproduct; $p->customer_name = 'John Doe'; ... $p->save();
    1 point
  23. First idea: This way you can change and modify it to your needs. See also: https://github.com/webworkerJoshua/privacywire/blob/master/PrivacyWire.module#L55
    1 point
  24. If you're looking for a JS library that pairs well with Tailwind, might I recommend Preline, which I just found on Hacker News: https://preline.co/ Another option includes Flowbite, but at the time of this writing, Preline's JS goes a bit further and has more components and more options (such as offcanvas, mega menu): https://flowbite.com/ There's also Alpine Components if you're into Alpine, however it's commercial: https://alpinejs.dev/components I like Alpine.js, but the "locality of behavior" approach it takes for these common components is not my style. I do use it elsewhere however. - Lastly, there's Headless UI, but that probably won't fit with a typical ProcessWire frontend unless you are using React or Vue: https://headlessui.com/ I wish Headless UI had a Alpine.js version, but the author of Tailwind ultimately scrapped the idea (it was mentioned in a Tweet thread somewhere). This would have been my go-to approach, assuming it was comprehensive enough. But there's many options as stated above.
    1 point
  25. Hey all. Currently getting an error message with later versions of ProcessWire, not sure when this started. When trying to edit a field: Fatal Error: Uncaught Error: Call to a member function getOptions() on null in site/modules/FieldtypeSecureFile/FieldtypeSecureFile.module:205 Guessing this crept in when the file/image fields were refactored. Uncommenting line 205 seems to work, not sure what effects it may have for now. Not sure if you are still maintaining this @Wanze but I use it on loads of sites.
    1 point
  26. By the way, I don't remember which version introduced this, but you can use $field->getLabel() instead http://processwire.com/api/ref/field/get-label/
    1 point
×
×
  • Create New...