Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 12/10/2019 in all areas

  1. Hi @k07n. Yes, I am OK, thanks ?. I do have some good news but cannot share it now. There was a bit of a rethink about the GUI/UX but we are making some great progress. Hi @Mikie I am not sure what you mean by custom data store. Currently everything will live in the site DB (i.e. accessible via ProcessWire's $database). I'd like to hear more about your line of thinking, thanks. All, sorry it's been a while since the last update. Rest assured that we are working on this as fast as we possibly can with great enthusiasm and motivation without sacrificing quality ?.
    7 points
  2. Updated to v0.0.5 on github New features: optional Ajax loading of thumbnails. Especially useful when field is used inside repeaters or has many images. edit link right next to the thumbnails for the page that supplies the images. When clicked, the images field that holds the images will be loaded in a modal window. After making changes to the images and saving, the thumbnails are dynamically reloaded Side note: while working on these, I discovered that you cannot assign custom attributes to InputfieldMarkup and InputfieldWrapper (both inherit from Inputfield class) with $field->attr('data-sth', 'value'). $field->setAttribute() also doesn't work. Anyone else also experienced this? Is it deliberate or a bug?
    3 points
  3. EDIT: all development and discussion of this module has been moved to Module FieldtypeImagePicker which now contains all features of this module and more. This module will not be maintained any further. The information below remains for pure historical reasons. I am happy to present my new fieldtype FieldtypeImageFromPage. It is made up of 2 modules: Fieldtype Image Reference From Another Page is a Fieldtype that stores a reference to a single image from another page. The image can be selected with the associated Inputfield. Inputfield Select Image From Page is an Inputfield to select a single image from images on a predefined page and it's children. And there also is a helper module that takes care of cleanup tasks. This module evolved out of a discussion about my other Module FieldtypeImagePicker. It caters for use cases where a set of images is being reused multiple times across a site. With this fieldtype these images can be administered through a chosen page. All images uploaded to that page will be available in the inputfield. When to use ? Let editors choose an image from a set of images that is being used site-wide. Ideal for images that are being re-used across the site. Suited for images that are used on multiple pages throughout the site (e.g. icons). Other than the native ProcessWire images field, the images here are not stored per page. Only references to images on another page are stored. This has several advantages: one central place to organize images when images change, you only have to update them in one place. All references will be updated, too. (Provided the name of the image that has changed stays the same) Features Images can be manipulated like native ProcessWire images (resizing, cropping etc.) Image names are fully searchable through the API Accidental image deletion is prevented. When you want to delete an image from one of the pages that hold your site-wide images, the module searches all pages that use that image. If any page contains a reference to the image you are trying to delete, deletion will be prevented. You will get an error message to help you edit those pages and remove references there before you can finally delete the image. How to install and setup Download and install this module like any other modules in ProcessWire Create a page in the page tree that will hold your images. This page's template must have an images field Upload some images to the page you created in step 2 Create a new field. As type choose 'Image Reference From Another Page'. Save the field. In 'Details' Tab of the field choose the page you created in step 2 Click Save button Choose the images field name for the field that holds your images (on page template from step 2) Click Save button again Choose whether you want to include child pages of page from step 2 to supply images Add the field to any template You are now ready to use the field View of the inputfield on the page edit screen: View of the field settings The module can be installed from this github repo. Some more info in the README there, too. In my tests it was fairly stable. After receiving your valued feedback, I will eventually add it to the modules directory. My ideas for further improvement: - add ajax loading of thumbnails Happy to hear your feedback!
    2 points
  4. Welcome to the forum, @Ovolion. It sounds like you would be better off using a dedicated e-commerce solution such as PrestaShop. Not that ProcessWire can't accomplish the same thing, but in this case I think it would be better to go with a dedicated solution. Just my $.02
    2 points
  5. /site/modules/ProcessMenuBuilder/ProcessMenuBuilder.css 178 line div.handle i.fa-trash { position: relative; border: none; padding: 0.6em; /*margin-right: -2.125em;*/ top: 1px; } fix: add comment margin
    2 points
  6. What about using $page->addStatus(Page::statusLocked); on the first save occourence? So when a page belonging to a survey is first saved, the next time is accessed it would have a status "locked". I'm not sure if your "admin" user also corresponds to a "super-user" role. In that case I would suggest assign to him a different role, in which case you should dismiss the hook logic and define granular edit permissions for those survey pages.
    2 points
  7. @kongondo, have U any good news for us? Just say you're ok ;)
    2 points
  8. Hi @benbyf Just ideas, I hope this helps: As far as I know, the closest module which at least partially could be used for such grid building is @Macrura's Inputfield Selectize: https://processwire.com/talk/topic/13549-selectizejs-modules-family/ Another idea – which also needs additional coding – but could be a working solution is to use @gebeer's new module FieldtypeImage Picker which is currently being polished: https://processwire.com/talk/topic/22665-module-fieldtypeimagepicker-pick-images-from-a-folder/ And for the grid part you could implement a grid builder with something like this: https://gridstackjs.com/ FieldtypeImage Picker could be used for setting the image, and the event of that selection could notify gridstack.js which could then set the content of corresponding the grid cell accordingly. As for uploading images on the fly, I have no idea about the possibilities, but if you can use ajax request in the correct order, then it might be possible to wire it all up. If a PW image inputfield is set to replace images with an already uploaded image having the same file name, then PW uploads and assigns the image to that page without the need to click the Save button, therefore images uploaded to the very same page could be made available right after being uploaded, provided FieldtypeImage Picker "be refreshed". You could consult Gebeer for such a possibility... Again, I am just brainstorming here.
    2 points
  9. I'd support @rick's advice. Setup, coding and everything around ProcessWire as eCommerce solution might already be too much effort in time and money just to get things rollin'. I don't know Prestashop but yet Shopify might be an option as well. Low fees, ready made solution with lots of features right out of the box. You and your client could split things - a shop on a subdomain and the marketing buzz on the main-domain powered by ProcessWire.
    1 point
  10. Just an opinion and the same @Gideon So already said but... this module should be part of ProcessWire by default. It saved me hours today. Literally.
    1 point
  11. Hi @Jonathan Lahijani - I've just seen the open issue in Github, which should be resolved now. Are you still getting the issue above on this latest version?
    1 point
  12. Same here. Build the site in html first and then implement whatever you want into it.
    1 point
  13. Thanks for testing. I have this behavior in my other module that allows to pick images from a single folder. But now that there is an option to also choose images from child pages, it would make the inputfield grow too high. Also if there are many images. I will implement ajax loading for the thumbnails on open and think that is better, especially for cases with many images or child pages or when the field is used inside repeaters. Good idea! Will add this. Maybe open in modal window and refresh thumbnails on close. Will be easy to implement once the ajax thumbnail loading is there. Thanks for the link. That would be one option but only works for installs which are up to date on the PW version. Repeater fields also open automatically if they have an error attached to them. That is another option. But implementation is quite complex. Still experimenting with this feature.
    1 point
  14. The first workflow is the more traditional way for me, I ensure the website is built first, then change them from HTML to Twig, since I am more of a fan of Twig than the default Processwire Engine.
    1 point
  15. Maybe this? https://processwire.com/blog/posts/pw-3.0.145/ See the Inputfield Javascript API
    1 point
  16. Hi @gebeer, nice module, thx for sharing! Just tested it and everything worked flawlessly. 2 suggestions for improvements: When no image is selected the gallery could be opened by default (I guess that is what one would like to do in that case: Choose an image) Maybe there could be a link to the page that holds the images so if one wanted to upload a new image they could just click the link, upload the image and save the page. If your inputfield updated its content after that process it would even be better, but not necessary in the first step, I think.
    1 point
  17. What @gebeer said. It could even be as simple as that in /site/ready.php if($page->template == "admin") { if(!$user->hasRole('your-role')) $session->redirect($pages->get(1)->url); }
    1 point
  18. Hi guys, thx alot for the discussion ? Good point. I think that should not be a problem. If there is an issue with the core, it should be easier to check a simple fix than to fix the issue yourself. If it was a complicated fix, this module might not be the right place for it. I've added @adrian as collaborator on the Repo - the goal is that this project is a "real" little community project ? --- Thx adrian, I've updated the description of the module: --- Actually I think it IS a module for the average user. See https://github.com/processwire/processwire-issues/issues/812 for example. This is a CSS issue that any webdeveloper can easily fix by some CSS rules. The only problem is: How to get the code properly into processwire. There are several possibilities: Overwrite the core css file (easy, but no option, of course) Create a PR (you don't know when it get's merged and you need a workaround until then) Use a module like Admin Custom Files (this works for CSS and JS, but this will not work if you need hooks for your fix) Add your fix via hooks in ready.php (you end up with a mess of hooks in ready.php and you need to copy over code snippets from project to project) Create a module for it (that might be too much effort for most users for simple fixes) The module makes it really easy to apply any kind of quickfix. And it makes it really easy to merge those fixes via PR's (for the ones maintaining this module). --- True! Nothing to add ? --- It's not intended for hacks, it's intended to fix issues that one would report in the PW issues repository until the issue get's fixed there properly. Hope that makes sense ? Thx, that's a good idea, thx ? --- Nice idea. I'm not sure how helpful automatic statistics would be though. I've got bad feedback on my modules implementing google analytics download tracking and numbers where small overall anyhow, so I'm really not sure how much help a "this fix was used 5 times since 08/2019" would be ? What do you think of a obligatory property for every fix that links to the related PW issue report. This would make sure that the issue is reported in the issues repo, seen by Ryan and users can vote for the issue there (give a thumbs up). That would also have the benefit that users can raise their voice there, comment things, add screenshots etc.; A lot better than some strange number where nobody knows what it shows exactly... --- Could you please try to do that on your own? I've added you as collaborator ? --- Thx again for all your contributions! Have a great week.
    1 point
  19. You can mimic a basic authentication in the file "site/templates/admin.php" Therefor you have to handle a set of valid usernames and passwords in that file too, like in the following example: <?php namespace ProcessWire; $validUsers = [ 'user1' => 'pass1', 'user2' => 'pass2', 'user3' => 'pass3' ]; $validAdminUser = false; if(isset($_SERVER['PHP_AUTH_USER']) && isset($_SERVER['PHP_AUTH_PW'])) { if(isset($validUsers[$_SERVER['PHP_AUTH_USER']])) { if($validUsers[$_SERVER['PHP_AUTH_USER']] == $_SERVER['PHP_AUTH_PW']) { $validAdminUser = true; } } } if(!$validAdminUser) { header('WWW-Authenticate: Basic realm="Adminsection"'); header('HTTP/1.0 401 Unauthorized'); echo '401 Unauthorized! Accessing this page needs a valid useraccount!'; exit(); } require($config->paths->adminTemplates . 'controller.php');
    1 point
  20. Hi @nurkka. Sorry for the late response. I have been away. This is an excellent suggestion! I'll have a think on how to best implement it but theoretically, it is doable. Another great suggestion! I would have to rethink the GUI a bit since tabs (Filter: Icons, Filter:Photos, etc) would quickly become unwieldy. On a related note, I have been planning to refactor the items shown in the Inputfield Selector (the filters) as there are a number of things not directly relevant to Media Manager that would confuse editors. For instance, the Inputfield shows non-Media Manager fields, items like Path/URL, etc. I am planning to work on your suggestions and the refactoring in the next update. I might call on you for a bit of testing before release, if that's OK. Thanks.
    1 point
  21. 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
  22. 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.
    1 point
  23. Imho, This functionality really should be in the core Gideon
    1 point
  24. In addition to this, I also recommend reading up about the very basics of Object Oriented Programming, http://www.tutorialspoint.com/php/php_object_oriented.htm at least the concepts behind it. Although in the case of ProcessWire frontend development you are not "forced" to implement anything in OOP, knowing the fundamentals helps a lot to understand the API and its usage. An often used technique in the OOP world is method chaining. You do not have to use it, but when you want to look up someone else's code, you need to how and why it works: http://www.xpertdeveloper.com/2010/09/method-chaining-in-php/ BTW I highly recommend bookmarking http://www.tutorialspoint.com/php/ You can use this method before you jump into your trial-and-error experiment: Whenever you start working on something unfamiliar, say sending emails, study some basics in pure PHP, say: http://www.tutorialspoint.com/php/php_sending_emails.htm After that, look for alternatives in the ProcessWire world: API support, module support Of course, it is recommended to use the API and/or modules whenever you can, but understanding why is so makes working with them easier. Hope this helps, good luck, and never give up!
    1 point
×
×
  • Create New...