Leaderboard
Popular Content
Showing content with the highest reputation on 12/16/2019 in all areas
-
I have made good progress and have a working version now, that allows to pick an image from a predefined page (and optionally its children), a folder inside site/templates or the page that is being edited. The version is available in the branch 'allinone' on github. Install from URL https://github.com/gebeer/FieldtypeImageFromPage/archive/allinone.zip If you find the time, please do some testing and report your findings. Thank you. If you test, please uninstall previous versions and install this one. EDIT: Also uninstall InputfieldImagePicker if you happened to install it. My code does not cater fully for DB update, yet. And since I switched field value storage to json, atm this has to be installed from scratch. The module is still on that repository. But eventually I will publish it on the ImagePicker repository when I feel it is ready. One thing I still have to solve: ATM the field returns 2 different objects for rendering in templates, depending on where the image comes from. If it comes from a page, you will get a Pageimage object. If it comes from a folder inside site/templates, you will get a custom ImagePickerFile object. The latter one cannot be manipulated (resizing/cropping) like a Pageimage but has some similar properties. I still have to find a way how to turn images from a folder that is not connected to a page into Pagimage objects. This is quite tricky. I wonder if anyone who is reading this has evr tried to accomplish something similar. I really always want to provide a Pageimage object, no matter where the real image file lives so that it can be manipulated. Still scratching my head on that but hope I will find a solution.3 points
-
Hi, here is ProcessPageToggle module and it is almost the same like @dragan post link to another forum thread, or what can be found inside Processwire Copy/Clone module. This is basic variant and need to be configured inside file, as example: // ProcessPageToggle.module // set action button label protected $actionLabel = 'Favorite'; // set page template(s) protected $templates = array('blog'); // set page checkbox field name protected $targetField = 'favorite'; Download, edit, and install like any other PW module. ProcessPageToggle.module3 points
-
Although the PW backend is really intuitive, ever so often my clients need some assistance. Be it they are not so tech savvy or they are not working in the backend often. For those cases it is nice to make some help videos available to editors. This is what this module does. ProcessHelpVideos Module A Process module to display help videos for the ProcessWire CMS. It can be used to make help videos (screencasts) available to content editors. This module adds a 'Help Videos" section to the ProcessWire backend. The help videos are accessible through an automatically created page in the Admin page tree. You can add your help videos as pages in the page tree. The module adds a hidden page to the page tree that acts as parent page for the help video pages. All necessary fields and templates will be installed automatically. If there are already a CKEditor field and/or a file field for mp4 files installed in the system, the module will use those. Otherwise it will create the necessary fields. Also the necessary templates for the parent help videos page and it's children are created on module install. The module installs a permission process-helpvideos. Every user role that should have access to the help video section, needs this permission. I use the help video approach on quite a few production sites. It is stable so far and well received by site owners/editors. Up until now I installed required fields, templates and pages manually and then added the module. Now I added all this logic to the install method of the module and it should be ready to share. The module and further description on how to use it is available on github: https://github.com/gebeer/ProcessHelpVideos If you like to give it a try, I am happy to receive your comments/suggestions here.2 points
-
A module created in response to the topic here: Page List Select Multiple Quickly Modifies PageListSelectMultiple to allow you to select multiple pages without the tree closing every time you select a page. The screencast says it all: https://github.com/Toutouwai/PageListSelectMultipleQuickly https://modules.processwire.com/modules/page-list-select-multiple-quickly/1 point
-
This is a little module that allows you to put your site into maintenance mode should you ever wish to. It basically checks to see if you're a superuser and if you're not then every page on the site which you try and load will send you to the login page with an appropriate maintenance message. The styles are hardcoded into the module at present, so changing the default style of the front-end EDIT button could well have a knock-on effect. Ideas for the future: I was also thinking about expanding this in future to allow chooseable roles in the configuration that can access the site whilst it's in maintenance mode, as well as adding the messages to the config so they can be translated. It might also be nice to specify another page to send the user to so that if you want to keep your admin login page hidden you can do. Thanks to adamkiss whose ListAfterSave module this was written over the top of Thanks to ryan for solving the last piece of the puzzle and helping me display the message in the top-left of every page. EDIT: And my particular usage scenario is that I'm building a site on a live server. It's a brand new site so nobody would really know the URL so I thought I'd build it in the root of the site rather than a subfolder and this module lets me do that without letting folks see it until it's finished. Other usage scenarios could include major template file updates or... whatever else you think it might be good for You can fined the module in the directory here: http://modules.processwire.com/modules/maintenance-mode/ v1.0.6 adds ability to bypass maintenance mode for certain user roles.1 point
-
We recently relaunched DOMiD, the Documentation center and Museum of Migration in Germany. Concept, design and implementation by schwarzdesign. Features Bilingual site with German and English A section-based design focusing on flexibility and ease-of-use for editors Multiple forms built with FormBuilder that can be placed on any page Separate feeds for news & press releases Lightning fast page loads with almost perfect ratings in Lighthouse Completely accessible and SEO-friendly Notable tech decisions Forms and form placement There are multiple forms for different services that DOMiD offers. Those are built with the FormBuilder. The editors don't have access to the FormBuilder itself, but we still wanted to allow them to control which form is displayed on what page. For this purpose, every page has a select field to select which form to include (if any). Additionally, the form placement has additional fields for a headline and a description, so a generic contact form can be reused in different contexts. Section-based design Most pages are built through Repeater Matrix sections. There are multiple section types available, for example: A generic text / image column with up to three columns of text and images An accordion (rendered as <details> elements). An image gallery Downloads (for files and images, displayed as a list of downloads) External Embed (e.g. YouTube) All sections have an optional headline and a selection of three different background colours. In addition, text columns may be rendered as a coloured block with some padding. This allows for interesting and diverse layouts. Testimonial database One of the available sections is for testimonials or statements (you can see one at the bottom of the homepage). Because one testimonial may be displayed on multiple pages and the client wanted to be able to switch the displayed testimonial on the fly, there's a separate content type for statements. The statement content type has fields for the statement text, author, and author image. The testimonial section only has a page reference field to select which statement to show. This way, the testimonial definition is separate from the placement on a page. Modules used Form Builder Pro Fields (Repeater Matrix in particular) Unique Image Variations ALIF - Admin Links in Frontend Sitemap Wire Mail SMTP Developer Tools: Tracy Debugger, Duplicator, ProcesWire Upgrade Migration museum As a sidenote for anyone living in Germany, this month the German Bundestag has approved funding for DOMiD's first Migration Museum ("Haus der Einwanderungsgesellschaft")! The museum will be build in Cologne and is scheduled to be finished by 2023. We're looking forward to it! Check out this page if you want to learn more, or find out what people are saying about it here.1 point
-
@Knubbi Is it a MySQL 5.5 or a 5.7 database? If you are using MySQL 5.7, you could try to migrate the tables to another MySQL 5.7 database. (If you create a new database, chances seems to be high there that it's created on another database server.) We also have problems with those errors, which, however, are not (or not only) caused by ProcessWire. (I've seen such errors in an Dev environment when we had just two users online... Have a look at some MySQL server stats, you very likely will find some signs of a heavily overloaded server. Contrary to their information about dedicated ressources regarding managed servers, Ionos (1&1) uses MySQL 5.7 database servers for several accounts in parallel, not just one for your managed server account.) If you are still using MyISAM, it also should be save to migrate to an MySQL 5.5 database instead. Whenever I compared server statistics, MySQL 5.5 servers at Ionos (1&1) had less problems than their MySQL 5.7 servers.1 point
-
This is basic PHP looping over an array. Since $blogimages is an array, you need to foreach over it to output every image in that array <?php $blogposts = $pages->find("template=blog-post"); foreach($blogposts as $blogpost){ $blogimages = $blogpost->images; foreach($blogimages as $image){ $imgthumb = $image->size(500, 300); echo "<img src='{$imgthumb->url}' alt='{$imgthumb->description}'>"; } echo "<h2><a href='{$blogpost->url}' >{$blogpost->title}</a></h2>"; echo "<p>{$blogpost->body}</p>"; echo "<br>"; } ?>1 point
-
Glad you sorted it! This is on purpose. Otherwise the filename would overflow the background area, especially on not so wide previews. Doesn't look very nice as it is, I know. In the CSS I had hyphens: auto; before but that would break the filename to the next line too soon. So I decided to go for word-wrap: break-word; instead.1 point
-
Really sorry for the trouble. Maybe caching issue? The 2 modules were never supposed to be installed alongside each other and I didn't take that into account since it is planned to replace the 'old' ImagePicker module with this one. Added a warning to my post above so others won't fall into that pit.1 point
-
Thanks for reporting. I was thinking about that one, too. But then I decided to allow only one images field because it might confuse users. But then, if I allowed multiple fields, the user could upload to any images field and have them available for the picker. Think, finally I will add this.1 point
-
Really short on time, but wanted to take a quick look. So far looks really great - thank you! I noticed this error - only occurs if the child page doesn't have images available. Also, I am wondering about the radio buttons as a way to choose the fields that images can come from. I would have thought checkboxes were better to allow for multiple fields. This may be for multiple fields on the one page/template, but I can see it also being useful for different pages with different templates that have different image fields. Does that make sense?1 point
-
You can have a look at my relatively new help videos module. Relevant code starts here. All the basics for creating fields and templates and pages are there. Should be easy to build upon. The uninstalling part goes in the ___uninstall() method. You basically need to keep track about what you installed (e.g. save this info to your module config data) and then remove that stuff.1 point
-
A bit off-topic, but while typecasting an empty array to boolean does indeed result in false, "empty($array)" has its benefits. It's slightly more verbose, but it also won't cause a notice if $array hasn't been defined yet, and it's arguably more obvious (leading to better readability). Relying on typecasting can sometimes result in obscure issues, as well as make the code ever so slightly harder to decipher. Using "count" to check if an array is empty is a common mistake. Even if in most cases the actual performance difference is too small to really matter, there's no reason to do this ??1 point
-
@Robin S I agree and this is already in progress. It's not in the first version but is in the next one—here's the relevant section from the draft documentation:1 point
-
The children results only have with built-in page fields. They don't have template fields. You have to make sure the field title exists in GraphiQL before querying it. When you go to Setup -> GraphQL and enter the above query it will tell you that there is no "title" field for children list. If the field is not in your GraphQL schema you cannot query it. If you want to query your task pages with template fields like title, you can set them as a Page field like you do with your job_client field. That way your tasks will have all the template fields you enabled.1 point
-
This week we’ve got version 3.0.147 out on the dev branch. Relative to version 3.0.146, most of the new commits (about 13 of them) are focused on resolving reports submitted at GitHub. I love refactoring existing code and adding optimizations and improvements to the core (and then writing about them in the blog). But right now I’m trying really hard not to! I’d like to have a new master version out before the new year, so the focus is on making sure the core is as absolutely stable as possible. Any time I refactor or add something new (or even sometimes when fixing something or another), there’s a chance of introducing new bugs, and it needs thorough testing on the dev branch, so right now the goal is that everything is thoroughly tested and stable before merging to the master branch. As a result, I’m trying to keep my hands off the core as much as possible, other than fixing obvious things that aren’t likely to introduce new code that needs testing. Please consider 3.0.147 release candidate 1 (RC1) for the next master. Thanks for all of your help and testing. Hopefully by (or before) 3.0.150, we’ll be ready for a merge to master. One way I try and take a break from modifying too much in the core before a master version release is to focus on other modules instead. That’s why last week I wrote about the new UserActivity module, and why next week I’ll be posting all the details for a new LoginRegisterPro module — one that I’ve been working on-and-off for more than a year, but have recently given it a lot of attention in getting it ready for release. I’ll save most of the details on LoginRegisterPro for next week, except to say that it provides an all-in-one solution for front-end login, account registration, profile editing and more. You might be wondering how that’s different from the LoginRegister module I built and released awhile back. That LoginRegister module was built for a very specific purpose and client, largely as a proof-of-concept. But there was a lot more interest in it than I ever expected, and several people suggested that there was a need that would be better served by the quality and support of a Pro module. The result is LoginRegisterPro, which is a full reimagining of that from the ground up. It does everything LoginRegister didn’t, in addition to everything it did. It goes much further in terms of security, reliability and customizability, and I look forward to telling you more about it. I may have it ready to release as soon as next week, but just wanted to make sure all the documentation was complete (and there is quite a lot of it so far). A couple other things I’m looking forward to working on here in the next month or so are the 2020 core roadmap and [finally] the new modules.processwire.com site. Thanks for reading and have a great weekend!1 point
-
@DV-JF, I thought that this module was too "minor" to belong in the modules directory, but I get that it makes it easier to find, install and update so I've added it now. It should get validated and appear in the directory soon.1 point
-
Hi ... Jonathan Lahijani has a great tutorial on youtube that can help you Simply put, you need to create an option template, then add 2 pages, one in the page tree named options, to which you choose the option template, and under the admin add another page and change the name, for example (admin_options), so that the names are not identical. Choose a process named ProcessPageEdit and save the page ... in admin.php paste the code // Custom Options Page if( page()->name == 'admin_options' ) input()->get->id = pages()->get('options')->id; Finally, you can add some css to hide the options page in the page tree. /** Hook Admin Custom CSS */ $wire->addHookAfter('Page::render', function($event) { if(page()->template != 'admin') return; // Check if is Admin Panel $value = $event->return; // Return Content $templates = urls()->templates; // Get Template folder URL $style = "<link rel='stylesheet' href='{$templates}assets/css/admin.css'>"; // Add Style inside bottom head $event->return = str_replace("</head>", "\n\t$style</head>", $value); // Return All Changes }); You can also download the profile that has the option page created and see how you can create your own options page https://github.com/rafaoski/site-minimal1 point
-
alan, you can use markdown or textile syntax in description fields. http://en.wikipedia.org/wiki/Markdown This was mentioned here: http://processwire.c...__fromsearch__1 Markdown is a module in PW by default (textformatter), textile version is also existent. you can, using markdown, simply do this to make links in field description : [linktext](someurl) *** corrected some1 point