Jump to content

Leaderboard

Popular Content

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

  1. Shetland.org is a website run by Promote Shetland which inspires people to visit Shetland, encourages people to move to Shetland to live, work and study, and attracts people to invest in commercial activities in the isles. We (NB Communication) have run the Promote Shetland service on behalf of the Shetland Islands Council since 2017, and as part of the contract undertook a project to redevelop the existing Shetland.org website. In this showcase we’ll highlight a selection of modules we used and what they helped us achieve. Visit the site: www.shetland.org Pro Modules ProCache We use this on almost every site we build. Indispensable. The cache settings used are pretty simple – most templates are set to 1 week, with the entire cache being cleared on save. We use ProCache’s CDN functionality to serve assets from CloudFront via c.shetland.org. We also use the API provided by ProCache to compile (SCSS), minify and collate our styles and scripts via $procache->css() and $procache->js(). We then use the URLs returned to preload the assets, making the site even faster! ProFields: Repeater Matrix Again, we use this on almost every site we build. Another must have Pro module. This module allows us to create a really powerful page builder field (we call it ‘blocks’) that handles the majority of the content on the site. On a simple development, we just use two block types - Content and Images - the latter displaying as a gallery or a slideshow. On this site we have 13 different types, including ‘Quotes’, ‘Video’, ‘Accordion’, and ‘Links’. Additionally many of these are configurable in different ways, and some render in different ways depending on the template and context. Have a look at the links below for some examples: https://www.shetland.org/visit/do/outdoors/walk https://www.shetland.org/blog/how-shetland-inspires-me-artist-ruth-brownlee https://www.shetland.org/life/why/teach-shetland-school NB Modules We also used a number of modules we've authored: Instagram Basic Display API Used to retrieve the 6 latest images from instagram.com/promoteshetland. Markup Content Security Policy Used to implement a CSP for the site. Currently scoring a C on observatory.mozilla.org – not the best score possible but significantly better than all the other destination marketing websites I tested (all got an F but one which was a D-). Pageimage Srcset Used throughout to generate and serve images of different sizes via the srcset and sizes attributes. This module is really useful if you are looking to optimise the serving of images to improve page speed times/scores. Video markup for YouTube/Vimeo This module was developed specifically for use on this website, as we wanted more control over the rendering of the oEmbed data. In the example below, the video thumbnail is displayed with a text overlay – when clicked the video (YouTube embed) opens in a lightbox. And a big shout out to… Page Path History The previous site was also built by us in ProcessWire, but a number of years ago now. The new site has significant changes to the sitemap, but 1000+ blog posts were also migrated. Instead of an .htaccess file with thousands of 301 redirects, we were able to use the functionality provided by this module to implement redirects where required, and in the case of the blog posts which were migrated via an import script, implement the redirects via the API - $page->addUrl(). ... The above is just a fragment of the features present on this site, and the development just a part of a much larger project itself. We're really proud of what we've achieved, and we couldn't have done it without ProcessWire. Cheers, Chris (NB Communication)
    17 points
  2. Hi @3fingers, Both a and c are part of an internal (proprietary) GraphQL API implementation. The short explanation is: A GraphQL query is generated from the filters when the form is 'submitted' The GraphQL endpoint is queried and returns results The result is rendered b would take an age to explain properly, but basically the query string ends up in sessionStorage (JS) and the filter strip JS checks this to set the active option(s). When the filter options are changed the sessionStorage values change too so that the state is essentially retained throughout the user session. I can't give you any indication on budget unfortunately. We run the Promote Shetland contract, which is much more than just the website, so the redevelopment project is effectively 'in-house'. Timespan was just short of 6 months (design/development) I think, I wasn't involved in the early stages so can't say exactly when it began, but my involvement as developer started in August and we launched mid-November. Cheers, Chris
    3 points
  3. Hi @johnnydoe Probably you should try to change session name for one of your installation in your site/config.php file. https://github.com/processwire/processwire/blob/master/wire/config.php#L217
    3 points
  4. Flexible content or page building I've mostly used RepeaterMatrix for this. I think looking at some of the examples above, something in the core would be welcome and something with maybe a simpler interface too. Thing is, in my case, I still probably need the flexibility of what I can do with RepeaterMatrix but just making it even simpler for site owners once I hand things over is welcome. I'll have a think about it. Admin theme improvements 99% of the time all I really need personally is to maybe change the colours. It sounds silly, but anything that shows clients you're paying attention to detail is good - which is why I love that you can link their logo into the masthead and they like that, but colour scheme is the obvious addition if it's something we can just set with a colour picker or by entering a hex colour value or something in the admin theme settings. Improvements to existing Fieldtypes and Inputfields Decimal is something I really need for any site with pricing, or if trying to build any basic ecommerce functionality so +1 for that as I don't think it's something that adds significantly to the core hopefully. Seems small enough anyway. External API I have had more requests in recent years as a developer along the lines of "do you do mobile apps" and for all projects I want to use PW as a backend, so if there was a JS API I guess that would help (don't really know) but I also feel like some of the REST API activity I saw a few months back by someone (sorry, don't remember much!) would help with that. File/media manager and more file sharing options I think it's great to keep the current ability to upload images/files where they're needed in a page (and I know you wouldn't remove that) but if we could use tagging to help categorise images/files and that helps build the file/media manager feature that would make sense. I still think the point of initial upload would more often than not be when you need to upload the file for a specific page, but on a few larger sites I've found myself uploading the same header image to a few different pages because it was appropriate although they weren't in the same tree, and it would have been easier to re-use with a file/media that's tied to the file/images field, so in those fields if we had "Upload" or "Choose from gallery" as options - giving the ability to set a different description, tags and cropping for a single image depending on where we need to use it, and then the file/media manager is in charge of making sure when we delete one instance it remains in the other image field. Does that make sense? It comes up for me more often on larger sites, but also giving folks one place to look to see what images are already available can prevent repeat uploads of the same image. Sure it doesn't add much overhead, but it's still overhead. Not sure I've got the right solution there but something that doesn't require breaking out of the normal workflow is more intuitive in my mind. I think my point is that you don't always want to re-use the same image in a CKEDitor field, you might want to have it in a single/multi image field on more than one page and that's currently not possible to my knowledge. EDIT: I know you could maybe use tags to achieve this, or a field that selects files somehow like ASMSeect, but there are occasions where you want to re-use and re-order and re-uploading seems to be the only way. Maybe my use case is so unique though that it's too much to bother with the more I think about it. Seems pretty unique anyway.
    3 points
  5. Look like you have to call $res = paymentCheckout() which return an array with the form. Then you just echo the form (echo $res[0];). https://github.com/benbyford/PaymentStripeIntents/blob/master/PaymentStripeIntents.module#L62-L139
    3 points
  6. That's simply bootstrapping PW in a command, then loading rockmigrations and doing $rm->createField(...);
    3 points
  7. Hi @ryan thanks for the great info about the future of PW from last week and thanks for the condensed list above. I agree with most of what's already been said, but want to add some points as I've been heavily working on several mentioned areas over the last year. IMPORTANT: Admin Theme As mentioned I've been working on a better admin experience for quite a long time. This is an example screenshot of RockSkinUikit (which I'm not using any more): My key goals have always been easy things: Make it easy to change ONE main color which does look good in most situations (because the secondary colors are gray) Make it easy to change the Logo Make it easy to add custom CSS/LESS -------- I am now using a custom Admin Theme module AdminThemeRock that does look similar to what I've built using RockSkinUikit: Again: Custom color, custom logo, that's it! -------------- Another one: Custom color, custom logo: ----------- Another one changing only the main color (page tree example): ------------- Learnings: If the core changes, my theme breaks!! That's a no-go. I've had to add several custom hacks to my theme that make it out of sync with the core. But important parts of the theme have not been hookable, so that was my only option meaning I have to pull all changes from the core into my admin theme module. I guess nobody else is as crazy as I am and that might be one major reason why we have not seen any other admin theme modules... My theme uses the old admin theme repo sources, because we do not have any source files in the core... https://github.com/ryancramerdesign/AdminThemeUikit/ PLEASE add the source files the core or in a separate repo that we can fork or help with PRs!! I've added you to my private repo on github so that you can see all the changes that where necessary for getting everything to work. For all others, here's an example of how my dirty core hacks look like: getNav() and getSearchform() are hookable methods that I added to my module. I've also built a frontend module that I'm using on my sites. There I use a simple but very effective technique that uses one single render() method to render several code blocks that I organize in files: // file structure foo |-- foo1.php '-- foo2.php bar |-- bar1.php '-- bar2.php // code echo $uk->render("foo/foo1"); echo $uk->render("bar/bar2"); This keeps the files organised and makes it very easy to do custom modifications before or after a file is rendered: $wire->addHookBefore("RockUikit::render(foo/foo1)", function ... ); $wire->addHookBefore("RockUikit::render(bar/bar2)", function ... ); Using a dom parser like https://github.com/paquettg/php-html-parser would even make it possible to modify/add/remove single html elements of the returned output! Of course having custom hooks would be more elegant and performant, but I wanted to mention this option nevertheless. Support for a Dashboard-Page That's another big thing for all my pages. I don't want to show the pagetree to logged in users unless they really want to see it! Take this simple example: Or this more beautiful one: The latter is taken from the Dashboard module which proves the big demand of the community for such a feature! I don't want to talk bad about this module here, I've shared my thoughts in the related thread with @d'Hinnisdaël and should maybe go for a beer with him when all this covid thing is over, but IMHO the module has two major drawbacks that would not be necessary! 1) It introduces a whole new concept to the PW admin that is already there. The PW admin is built upon inputfields and it would be very easy to build a dashboard (or to be more precise, the dashboard widgets) using these existing tools. (this is built using inputfields). 2) Making the admin show the dashboard instead of the pagetree feels hacky in several situations. We've discussed that here: One problem is, for example, that the breadcrumbs do not work as expected any more. Clicking on breadcrumb "bar" in " foo / bar / foobar " would take you to the dashboard and not to " foo / bar ". ############################################ Would be great: Migrations I think the core and all modules could benefit greatly from easy api migrations like I have built in my RockMigrations module. It's far from perfect, it's not very well documented, but it does some things right in my opinion and that's why I have it in all my installs and nowadays have it as requirement for almost all my modules that I build. Why? Because I want to have my fields under control of GIT Because I want to write an easy setup file that creates all fields/templates/pages that I add to this codeblock Because I want to push changes to my live server without exporting fields via mouseclicks, then updloading json files, then going through a migration click-marathon again, when I can simply do git pull & modules refresh Because I want to be able to create reusable components easily. I know that one can do all that using the standard PW API and creating a custom module, but take this example and see how easy and clear things get when using RockMigrations (or even better a solid core migrations API): I've recently added an example module that shows how I'm using RockMigrations now: https://github.com/BernhardBaumrock/RockMigrations/blob/master/examples/MigrationsExample.module.php ############################################ Brainstorming: ProcessWire without DB We all love ProcessWire and it's tools, but there's one drawback: The great API is only available if we have fully installed version of ProcessWire available. That has been a problem for me when I tried to work on a module that installs ProcessWire automatically (PW Kickstart and now working on RockShell). Examples of such classes that might be useful even without a DB connection could be: WireData WireFileTools WireRandom WireTextTools WireHttp Sanitizer I know that there are several cases where DB settings are absolutely necessary (for example page data or sanitzier settings), but there are other frameworks, that show, that such a concept can work and make a lot of sense: https://nette.org/ One might argue, that this might be going too far... But if we are talking about the future of PW, why not thinking of something like this: // copy files to root folder include("index.php"); $wire->install([ 'user' => 'demo', 'pw' => $wire->random->alphanumeric("8-12"), ... ]); Or take another example: https://processwire.com/api/ref/wire-mail/ There's no reason why we need a running PW instance with a DB connection for such a code example. Of course I know that it's technically required in many places in the core, but maybe these places could be identified and removed in the future?! Or maybe PW could support noSQL or something? ############################################ Would be great: A better Date/Time/Range-Field (dream: Support for recurring dates/ranges) I've started a discussion here and as you can see the post got a lot of attention: ProcessWires date field is nice, but it is a PAIN to work with date ranges, to build calender-like applications, to get the proper entries from the DB, etc... Why? Because the only option right now is to add TWO date fields to one template and there the problems begin... What if you want to make sure that one date is after the other? What if you want to show all events of one month? There's a HUGE potential for bugs like "foodate < $lastOfMonth" should have been "foodate <= $lastOfMonth" How to get the timestamp of $lastOfMonth properly? An API like https://carbon.nesbot.com/ would be great! What if events can have a range (like from 2021-01-10 to 2021-01-15), but can also be a single day event (2020-12-24). What if an event is on one day but has a start and end time (2020-12-14 from 18:00 to 22:00)? What about timezones? How to do the proper formatting? Showing a date like this "2020-12-24 18:00 to 2020-12-24 22:00" is a lot worse than "2020-12-24 18:00 - 22:00". This gets even more complicated when you want to show the days... What if you want/need to handle recurring events...? ############################################ PageBuilder I've taken several runs on that topic and finally (?) found a good solution during development of one large project last year. My approach was to make a new Fieldtype similar to Repeater and RepeaterMatrix, but with some big conceptual differences (it's more like Repeater than RepeaterMatrix): Every item is a single page in the tree and has a custom template Every repeater item can live anywhere in the pagetree Every item is defined in a single PHP file (using RockMigrations to make it reusable) This makes the setup very flexible on the one hand, makes it reusable across projects (simply copy the file and do a modules::refresh triggering the migrations) and makes it REALLY simple to use for the clients on the other hand: Setting up such a block is quite easy: class Headline extends \RockMatrix\Block { public function info() { return parent::info()->setArray([ 'icon' => 'header', 'title' => 'Überschrift', 'description' => 'Fügt eine Überschrift auf der Seite ein.', ]); } public function init() { $this->addHookAfter("Pages::saveReady", $this, "saveReady"); } // this method makes it easy to customize the item's edit-form // you can change labels, collapsed state, add notes or custom classes etc... public function buildForm($fs) { if($f = $fs->get('title')) { // dont show label for this inputfield $f->skipLabel = Inputfield::skipLabelMarkup; $f->wrapClass('rmx-pd5'); // add class to remove padding } } // the label of the repeater item public function getLabel() { return $this->title ?: $this->info()->title; } // migrations for this item public function migrate() { // the parent migrate creates the necessary template for this block parent::migrate(); // then we set the title field optional for this template $this->rm()->setFieldData("title", [ 'required' => 0, ], $this->getTpl()); } // code to use for rendering on the frontend public function render() { return "<h3 class='tm-font-marker uk-text-primary'>{$this->title}</h3>"; } // optional saveready hook public function saveReady(HookEvent $event) { $page = $event->arguments(0); if($page->template !== $this->getTpl()) return; if(!$page->id) { $page->title = "This is my initial headline"; } } } As you can see in the screenshot, I'm using CKEditor for editing fulltext. That's great, because I can remove all plugins that do usually need more education for clients (like inserting images) and build custom blocks solely for this purpose that every client can grasp a lot quicker and where I have a lot more control and freedom (since the block is a separate template). This means I've always had the freedom of custom image fields even before the image field supported them. Another example: A gallery block (headline + image field): I'm not sure about the scalability of this approach, but having all blocks as custom pages is a huge benefit in many ways. For example I could create a Matrix field having invoice items. Each item would be a page of type "invoiceitem" and then I could query all "invoiceitems" using RockFinder and build an average invoice NET or GROSS value of all invoices of 2020... Access control, page status, etc etc are still challenges though, of course. ####################### I hope that all makes sense and I'm willing to share any of my modules code if that helps. Or give you a demo/walkthrough via screenshare. One last question, as we are talking about the future of PW: One thing is what would happen to the core of PW if anything happend to you @ryan. But we could at least fork the core and do... whatever then would be necessary to keep all our businesses running and all our clients happy. But what about all the Pro modules? We could not get a copy of them and work on ProCache for example on our own (as a community). Did you think about that szenario and have a reassuring anwer for us? ? Of course, I wish you a long life and many happy years of developing PW - it's absolutely impressive what you have built here ?
    3 points
  8. Hi everyone, Thought I'd kick off this new dedicated support forum with a feature requests thread. Feel free to post your ideas for consideration. Cheers, Adrian
    2 points
  9. We've finally created the first dedicated forum for a module so I'm locking and pinning this topic for reference. If you need to ask questions/give feedback, please start a new topic in this forum. Thanks!
    2 points
  10. This gets an A for awesome! And big thanks for the modules. They look pretty neat as well.
    2 points
  11. I expect you are trying to use $files inside a function or there is some other reason for it to be out of scope. Try: wire('files')->find()
    2 points
  12. Did you also restart your WebServer? You can verify your current max_filesize with a simple phpinfo lookup. <?php phpinfo(); ?>
    2 points
  13. @LostKobrakai In addition to what I've mentioned above, I openly admit I'm not great at PRs, if that's what you are looking for an admission of. I try and make up for it in other areas. Nobody is perfect and one area I have work to do is getting better with PRs. I stated earlier that this is a priority for 2021. I will revisit the PRs that you mentioned. Maybe some think it looks bad to have open PRs, but to me it looks like enthusiasm, ideas and potential. I consider it an honor anytime someone would want to contribute in this way. I actually think the majority of PRs have a lot of merit and like what I see. I almost never would say "no" and close a PR in the way you are suggesting, because I almost never would feel that way. Instead, I look for the same crossover of priorities and timing that I do when it comes to adding new features. I like having a solid repo of PRs because it's stuff that is available for when the time is right and stuff I can refer back to and know someone else is also interested. All open PRs are a "yes" in my mind and just a matter of timing. Though going forward my hope is to find more time to cover open PRs even before the timing is right, since the community has indicated this would be helpful in appearances. PRs only don't age well if taken as literal code, which is not the way I work with PRs. It doesn't matter to me if the literal code has not aged well or not because it's the ideas that matter much more. Whether PRs or not, and whether my own code or not, I go through code additions line by line multiple times, often writing and re-writing, both for QA and to fully understand the logic... so I do not care about age of any particular code. I just care about the idea, getting it right and being able to support it for the long term.
    2 points
  14. @Sascha Nos You can output third level by declaring it in your module config https://github.com/ryancramerdesign/ProcessHello/blob/master/ProcessHello.info.php#L42 https://github.com/ryancramerdesign/ProcessHello/blob/master/ProcessHello.info.php#L50 And if I not mistaken if you want to output some dynamic items you can implement executeNavJSON method like https://github.com/processwire/processwire/blob/d8945198f4a6a60dab23bd0462e8a6285369dcb9/wire/modules/Process/ProcessTemplate/ProcessTemplate.module#L143
    2 points
  15. Last week I asked you what you'd like to see in ProcessWire in the next year (and years ahead), and we got a lot of feedback. Thank you for all the feedback, we've had a lot of great and productive discussion, and of course feel free to keep suggesting things too. Below is a summary of things based on what I thought was feasible from the feedback so far. I'm not suggesting we'll be able to do all of this in 2021, but do think it makes a good preliminary roadmap of things to look closer at and start working on some very quickly. I'll keep working to narrow this into a real roadmap, but wanted to share where we're at so far (consider it preliminary/unofficial): Flexible content or page building One of the most common themes has been that people want more content building options as an alternative to using a rich text editor at one end, and page builder at another. This is a direction that some other CMSs have been going in (like WordPress), and one that many would like to see ProcessWire provide an option for as well. But the needs seem to come from two different angles, and it points to us pursuing 2 directions simultaneously: First would be a flexible content block style editor in the core as an alternative to rich text editor that supports pluggable block types while maintaining best content management practices. If possible, we'd use an existing tool/library like editor.js or another as a base to build from, or potentially build a new one if necessary. To be clear, it would not be a replacement for CKEditor but an alternative approach supported by the core. Second would involve improvements to Repeater/RepeaterMatrix that enhance its abilities in supporting those using it for building more complex content page builders. Since many are already using it for this purpose, the goal would be primarily to better and further support this use case, rather than make Repeater/RepeaterMatrix a dedicated builder. Jonathan Lahijani and others have pointed out some specific things that would help achieve this and I plan to implement them. Admin theme improvements We would like to add additional flexibility to the AdminThemeUikit theme so that people can further customize it how they would like it. What directions this will take aren't nailed down quite yet, other than to say that it's going to be getting some focus (and this has already started). At the very least, we know people want more sidebar options and the ability to tweak specific CSS, perhaps in a preset fashion. Improvements to existing Fieldtypes and Inputfields Things like support for a decimal column type, more date searching options and additional input level settings on other types. Though these are specific feature requests and our focus is more broad, so we'll be going through many of the core modules and adding improvements like these and more, where it makes sense. Pull requests and feature requests People would like to see us expand our code contributor base by merging more pull requests in cases where we safely do it. We will also be narrowing in on the specific feature requests repo to see which would be possible to implement this year. External API There are requests for an external/front-end API that would also be accessible from JS. I support the idea, but have security concerns so am not yet sure if or in what direction we might take here, other than that I would like us to continue looking at it and talking about it. File/media manager and more file sharing options There is interest in an option for a central media/file manager so that assets can be shared from a central manager rather than just shared page to page. There is also interest in the ability for file/image fields to reference files on other file/image fields. External file storage Some would like to be able to have PW store its /site/assets/ and/or /site/assets/files/ on alternate file systems like S3. That's something we'd like to use for this site too. To an extent, work already started on this last year with some updates that were made, but there's still a long way to go. But it will be great for sure. Live preview and auto-save There are requests for live preview and auto-save features to be in the core. Currently they are just in ProDrafts, but there are now more options and libraries that would facilitate their implementation in the core, so I'd like to see what we can do with this. More multi-site features There is interest in ProcessWire natively supporting more multi-site features, potentially with the option of working with our multi-language support.
    1 point
  16. Your timing is excellent - I have a couple of projects where for one reason or another (sometimes it's on purpose) I have customers that are superusers and I'd like a way to exclude specific superusers from seeing Tracy if possible?
    1 point
  17. @Jozsef Used Ryan's TexformatterVideoEmbed and it works now. Thanks for guiding me there.
    1 point
  18. 1 point
  19. Thanks again for the report @Robin S - should be fixed now.
    1 point
  20. 1 point
  21. I am talking about using dev as a subdomain, eg dev.mysite.com
    1 point
  22. That’s cool - I’m glad it worked out well for you.
    1 point
  23. Thx, i've corrected that in case your wording is more clear ? Exactly. Sounds good to me in your wording as well ? Not sure how the image reference field works, though. I've never found time to give it a try...
    1 point
  24. I guess you meant "copied over to" instead of "uploaded to", correct? Anyway, I like this idea. If there was a central and configurable image browser (the image sources could be defined by the developer), so that admin users can re-use images by copying over images of a page to another page than that would help. Such a feature has its cons of duplicating the image, but on the positive side there would be no need to manage dependencies.
    1 point
  25. Fantastic site all-round and a great write-up here. Well done on the project, and thanks! ?
    1 point
  26. Hi @Zeka, great, that did the trick! Thank you very much ?
    1 point
  27. What a project! ? May I ask you some insights? a. Very clever use of the interactive map https://www.shetland.org/map. How you have managed the interaction between the custom search nav and the map reactivity? b. On the vacancies page, how you have made a relationship between the url query string and the filter strip? c. Any insights on you've built the inner search functionality? I'm particularly curious about the ajax refresh ? Last one, I promise: Could you give us a roughly timespan of the project (design and development phases) and an brief indication of the budget your agency had? Thanks and thumbs up again! ??
    1 point
  28. 100% agreed ? Just thinking out loud... If we were building a website with a blog. And every blog post had fields "title, coverpic, body". And if the "coverpic" field was set to that all uploaded coverpics lived in /site/assets/files/coverpic. And if we then created some new blog posts... First, we'd create PostA and upload coverpic "foo.jpg". That would live in /site/assets/files/coverpic/foo.jpg; Then, one week later, we'd create PostB and wanted to use the same image (because it was some stock image that is used for every blog post that showcases any event)... We could have the option to upload a new image or choose an existing one from /site/assets/files/coverpic which would mean that no additional storage would be used, because it was just a reference to /coverpic/foo.jpg If PostB was deleted, the image would need to stay available as long as no other field references the image (here PostA). Or maybe even better, if the storage path would be totally free to choose, eg /site/assets/files/blog/[...].jpg ?! --- For some of my clients that would for sure be great. They do now have a shared folder (dropbox), where they save images that they need on a regular basis for their website and then upload those files again if they need it. OK, but not the best solution. My described solution would change quite a lot in terms of PageImages I guess, so maybe as a quick win it would be better to just extend the file/image field with a file chooser, so that one can browse existing files of the same field (or of a definable set of sources) and when clicked, the image got uploaded/copied to the current page destination (eg /site/assets/files/1234/foo.jpg) meaning there'd be an additional copy (little overhead) but using existing concepts and having no complex changes behind the scenes ?
    1 point
  29. Thanks for your quick work on this @Sebi. That seems to have fixed it for us!
    1 point
  30. Hi Adrian, The expand and collapse icons in the Dumps panel are not clickable. Probably a z-index issue.
    1 point
  31. It was fixed after 3.0.165 master was released: https://github.com/processwire/processwire-issues/issues/1247 You can upgrade to the latest dev release to get the fix.
    1 point
  32. Wow - totally missed the discussion here!!! That's why the page-builder-part in my post in the newer news-thread was somewhat offtopic... I'll reference it here and throw it into the discussion ? Let me comment wildly on some statements first - I'll try to summarize that in the end... Yes, this makes sense. This is what I liked about that editor.js option, as it seems like (combined with its plugins) it's already a clean system for doing this. Interested to hear of others think this approach would be a good path to take. Please. No! I've done some research before starting with RockMatrix and editorjs was an option that I looked at. I decided against that approach. I can't really explain, but I had the feeling that this is some 3rd party concept and not the way ProcessWire would do content management. I had the feeling, that if we used something like editorjs we'd need to develop a totally new concept for all the content blocks. But WHY should we do that? WHY would that be better then using existing ProcessWire concepts? We have everything we need (speaking about Fieldtypes and Inputfields) and throwing that away would not be clever imho! Take a look at my matrix setup: First block is a headline - a regular PW "title" (text) field. I'm just removing the inputfield's header (we can already do such things easily via hooks!) Second block is a ckeditor field - similar, we remove the header and allow just a subset of usual ckeditor buttons. For example the image button is removed, because images are inserted via their own custom blocktype (gallery). That approach has several huge benefits that by far outweigh the drawbacks: Blocks are PW pages, this means you can do all kinds of PW magic with them. Think of hooks, think of custom page classes, think of doing listings using RockFinder (for example I'm using RockMatrix to hold invoice items having a description, an amount and a price and I can simply query all those items with a simple find call like "template=invoiceitem, year=2020") etc.; What about Multi-Language?! How would one build an editorjs field that properly reflects the internal PW multilang system?? What about file uploads? We know that files need pages and corresponding folders... We use existing, proven tools (fieldtypes/inputfields) Exactly. That's what I've built my matrix field for and that's what I need in every project. @Autofahrn has also put a lot of work into that topic! That sounds great. My matrix field does not allow nesting and showing items side-by-side or dragging dem from one block to another. But so far this has not been a problem at all! Quite the contrary. My clients love the ease of use. Even Non-Tec people can build great looking sites within no time. See these examples: https://www.kaumberg.gv.at/naturparadies-kaumberg/wanderwege/bergsiedlungsrunde/ https://www.kaumberg.gv.at/gemeindeamt-buergerservice/aerzte-therapeuten/gemeindeaerztin-dr-alexandra-hutsteiner/ https://www.kaumberg.gv.at/gemeindeamt-buergerservice/gemeinde-mitarbeiterinnen/ And using the same content blocks for a totally different topic: https://www.kaumberg.gv.at/gastlichkeit-tourismus-betriebe/betriebe-in-kaumberg/ This is SO flexible. If they needed any new content type (eg Youtube Video) I'd just add another matrix block and they could add videos everywhere on their website. I'm avoiding the PW admin more and more. I'm doing most of my work in RockMigrations nowadays, because it turns out that this often is quicker and less tedious than clicking around through the admin, replicating the changes on dev/live, rolling back changes manually etc etc.; Using migration scripts on the other hand I have my code in GIT, can just copy over parts as needed (git pull/git push), or simply use MultiCursor in my IDE to change the "columnWidth" setting of multiple fields at once (does anybody want to count the clicks necessary for changing 3 fields' columnWidth setting in the PW backend? ? ). I don't want to say that the PW backend is bad. Not at all. I've even wondered what @LostKobrakai is talking all the time when he showcased his migrations module back then, but I want to say that the PW backend might be really nice to have for simple use cases and beginners, but it is definitely a burden when dealing with advanced setups (think of automation, CI/CD, maybe multiple people working on one project at the same time, etc, etc). But I'm not voting for editorjs route here either! When I looked at editorjs and how plugins are built, that was a whole new world. I don't know much about all those modern javascript related dev tools and I don't really want to learn them, to be honest. Maybe that's the problem and I'm not being fair. But creating a new matrix block in my case is simply creating one single PHP file that extends \RockMatrix\Block, that's it... And I'd love to see such a setup in the core or a professionally supported one as pro module ? Sounds great ? This gets totally easy when using RockMigrations!! That's another reason why a solid migration system should definitely be part of the core! Everything would benefit a lot from such a core feature - module development, devs developing sites and reusing parts, etc... That would be a dream. Though I say again that I much more prefer defining things in code. Building user interfaces can be soo hard, while adding a hook can be so simple, efficient and clear. For example defining allowed blocks in RockMatrix is done like that: $wire->addHookAfter('RockMatrix::getAllowedBlocks', function($event) { $field = $event->arguments(0); $page = $event->arguments(1); if($field->name !== 'rmtest') return; $event->return->add([ '\RMDemo\Headline', '\RMDemo\Markup', ]); }); Imagine you had to build this as GUI... Sounds not too complicated, because you could use an ASMSelect field that lists all blocks and makes them selectable and sortable. But what if you'd want to show some blocks only to some special user role and hide them for others?! A simple if-statement in the hook. Nearly impossible to build as GUI... *emotional* Please, don't ? I've created a video that hopefully helps you all to get an impression: I think it would be helpful to clarify WHERE this discussion should happen upfront. In the forum? Via e-mail? Opening an issue (I think that's not the right place)...? But yeah... thinking about it I can imagine that monitoring all those channels is not easy and must take a lot of time...
    1 point
  33. @ryan is it possible that the community funds the development of the content builder? Can you think of a number we can set and try to collect? We can at least try this model)
    1 point
  34. Just adding my voice from a user perspective. I am not a coder but a very happy user of processwire. For some of my sites I use the repeater matrix apporach which was done for me by someone from the forum, great work. End of last year I decided to buy access for one year to thrivethemes.com a builder for wp, simply because my business model needs landing pages, email squeeze pages, courses, etc. etc. I get sick already with the trouble of learning how to do stuff in thrivethemes environment. Everything I built so far is far slower than what I have in pw, but for pw I need developers everytime I need something new. The guy behind thirvethemes now has 70 people working, so there is a market for this type of stuff. I much prefer what I have in the repeatermatrix pw way of doing things, and would therefore be SOOOOOOO happy if this gets taken further and I beleive if a few of you coding ninjas would build the pw version of thrivethemes, there is a market waiting to be tapped into. Just my 2 cents! Love the discussion and the talent gathered here.
    1 point
  35. Hi @ryan - it's been a great year for the PW core - thanks for all your hard work as always and very glad to hear that pro module sales are doing so well for you! In addition to the requests repo that @Robin S mentioned, there is also of course the https://processwire.com/talk/forum/5-wishlist-roadmap/ thread. I actually think it would be best to start with the issues repo and once those are all fixed, then move onto those two requests lists. Lots of user input has gone into those lists and I'd hate to see that effort ignored or pushed aside in favor of new suggestions. I have lots of new suggestions / ideas, but I think they should wait so your efforts can focus on outstanding issues first - does that make sense?
    1 point
  36. I think this is a helpful post for anybody new to hooks: https://processwire.com/talk/topic/18037-2-date-fields-how-to-ensure-the-second-date-is-higher/?tab=comments#comment-158164
    1 point
  37. Thank you for quick reply! I will take a look at it. I see composer installation really useful because I've just specified all dependencies in composer.json file and don't have to commit modules into my site's source code. So, when I deploy the site to production the automated script easily install all dependecies. All I have to do manually is to install the modules via admin (maybe this could be automated as well) or refresh if they are already installed. I've even created a "wrapper" composer package for processwire (see https://github.com/uiii/processwire), which will install like a regular installation, or upgrade the existing. So my site's source code only contains the site folder (without modules) and composer.json (and composer.lock) and this is enough basis to setup the whole running site by single command: composer install
    1 point
  38. $fieldgroup = $template->fieldgroup; $f = $fieldgroup->getField($fieldName, true); // Do stuff $fields->saveFieldgroupContext($f, $fieldgroup);
    1 point
  39. You can always reset your password just by pasting this temporarily into any one of your templates, and then viewing a page that uses the template: $u = $users->get('admin'); // or whatever your username is $u->of(false); $u->pass = 'your-new-password'; $u->save();
    1 point
×
×
  • Create New...