Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 01/21/2019 in all areas

  1. I noticed this as well and was going to comment about it :-). You are right it currently lacks consistency. When viewing API variables, the sidebar is in context. It should be the same when viewing Functions API. I also agree with all the other points you've raised @Tom. @ryan, Could you please consider reverting the API reference to the single column it used to be? Maybe it's just me, but I am finding the two-column layout confusing. My suggestion would be: This link: https://processwire.com/api/ref/ leads to a one-column layout page with short summaries of the topics (lack of a better word) in the API reference. Something like: API Reference API Variables These are Lorem ipsum dolor sit amet, consectetur adipiscing elit. An est aliquid, quod te sua sponte delectet? Duo Reges: constructio interrete. Videsne quam sit magna dissensio? Quis est tam dissimile homini. An potest, inquit ille, quicquam esse suavius quam nihil dolere? At hoc in eo M. Si quicquam extra virtutem habeatur in bonis. Et quidem iure fortasse, sed tamen non gravissimum est testimonium multitudinis. Read More... (linking to ..api/ref/api-variables/) Core Classes Quippe: habes enim a rhetoribus; At multis se probavit. Quid, quod homines infima fortuna, nulla spe rerum gerendarum, opifices denique delectantur historia? Unum est sine dolore esse, alterum cum voluptate. Quodsi ipsam honestatem undique pertectam atque absolutam. Itaque eos id agere, ut a se dolores, morbos, debilitates repellant. Read More...(linking to ..api/ref/core-classes/) Functions Tantum dico, magis fuisse vestrum agere Epicuri diem natalem, quam illius testamento cavere ut ageretur. Homines optimi non intellegunt totam rationem everti, si ita res se habeat. His similes sunt omnes, qui virtuti student levantur vitiis, levantur erroribus, nisi forte censes Ti. Read More...(linking to ..api/ref/functions/) Etc.. When I land on the API Variables page, all I would see are API Variables stuff, with the contextual sidebar menu showing API Variables stuff only ($page, $pages, etc). When I land on the Functions page, I would see the Functions stuff with a contextual sidebar showing Functions stuff only. Verbosity I agree with previous comments about verbosity on this page but since this is a getting started section, maybe it's not too bad. And it's one of those things; some like verbosity, others don't. I know and appreciate it took a lot of time to write this up. Writing documentation is not easy. However, if you take some time away from the writing, step aside and revisit it later, you will see stuff like these jump at you: Under the section You are always accessing the same exact thing. The word 'Regardless' is used 5 times :-). What I am saying is that there is room to make this documentation a bit tighter and to the point without losing the audience to curtness/brevity. That aside, please consider removing this line: I think it is leading to more questions without providing answers. For a getting started section, I would expect to at least see a link to 'come across more'. I would ask, what are those more? Why are there more? Where would I come across them? Other Minor Issues I'm not sure how the 'pages' plural and 'page' (singular) phrases will work when the site gets translated to other languages. Other languages will not be able to state: plural and singular in the same way. I suggest instead, to highlight or bold the words. I think it is pretty clear that pages and page are different. There were some other things but I forget. I may revisit this post or post another later ?.
    6 points
  2. I think that the new documentation is more confusing than previously. At the begging it only shows a handful of variables, so I use $files->render() to put the header and footer in each template. I don't use Regions or anything like that as we very rarely have absolute consistency between each page. For example sidebar etc. We often keep the design across each page but the layout is different depending on the content. $files is now hidden a long with a lot of other variables. As far as I can tell, we are pushing the Functions API unless there is a reason not to use it (multi-install etc.). That's great but the documentation isn't the same. For example $files has everything in there render() etc. Meanwhile the files() page just has $wireFileTools = files(); and nothing else. I feel like if we are going to favour the Functions API there needs to be an emphasis on this in the API Reference. At the moment it's a little... overwhelming? I feel like it should be a tabbed layout, where the variable API is under a different tab, then the functions API is first. I also think that it should be listed as it was previously. I don't know, it kind of feels like we are pushing the Functions API as it's beginner friendly, but the documentation for that part is definitely not beginner friendly. Another thing for me is if you look at a Functions API function in the documentation the left hand sidebar pushes you towards the Variable API, I can see that also get confusing. I think because the Functions API and variable API are essentially the same, I feel like having them all mashed together will get confusing with beginners using a mixture of both in their templates. EDIT: I just found out that you can't use the Functions API while using files()->render(), so in my _header.php page() returns Fatal Error: Uncaught Error: Call to undefined function page() in _header.php:5 I guess it's something to do with scoping. So it's looking for the template _header? I'm unsure exactly. Would this also be the case for rendering fields? Like repeaters etc. If this is the case, I really can not agree that using Functions API is more beginner friendly. I do like the way it looks but I'm unsure if it's better for beginners at all. I mean, I'm definitely not a beginner and it's confusing to me. EDIT 2: After some research, you have to use $this->page('title') or $this->page()->title which is longer than $page->title. I guess maybe I'll look at a markup region method. Maybe I should be updating my template rendering approach? It would be good if there was a guide of "Best Practice in ProcessWire 2019" or something. At the moment things are lost in blog posts etc. Would be good just to have a new "Starter guide" page that talks about preferred output methods especially when it can cause issues with the functions api. Having looked at markup regions in the past, I just don't know if they are more confusing as it requires a more advanced setup such as editing the config page, but also looking at site-default site profile, the site content is passed through as a variable, which to me just doesn't feel right with more advanced layout websites. EDIT 3: Okay, so after some playing around, you can use a traditional approach to the templates using Functional API. files()->render() does not work, however, wireRenderFile() does. I don't have the technical knowledge as to why. But if you use wireRenderFile() you don't have to use $this->page() but page() will work fine. It's definitely a different way at looking at ProcessWire. I'm just keen to keep myself up to date with the latest, lets say 'code style guide' as that's important to me. If we are favouring the Functional API in future, then I'd want to start using it straight away. EDIT 4: Sooo.... wireRenderFile() works on the homepage, but not any other page so it seems. Yeah, this is just really confusing for me. It's a shame because I do really like the more shorthand way of writing. I just think it's not as simple as $page as it seems to be causing confusion with rendering files. I've tried every method and here is what I've found. Homepage: Works with wireRenderFile() and use of page(), it also works with files()->render() and the use of $this->page() Any other page: Doesn't seem to work with anything, you can use wireRenderFile() or files()->render() with $page but any form of include or render on a non homepage doesn't work with Functions API. EDIT 5: Okay, I haven't gone back and updated the OP, because I would like to document the experience of someone new exploring the Functions API. It appears that any wireRenderFile or files()->render() will work if you define the ProcessWire namespace within the _header.php, I don't know if this is an issue with the TemplateFile compiler. But if you define the namespace at the top of an included file, everything works as intended. EDIT 6: Having played with the Functions API for a while, I think it's definitely cleaner. I think one thing could be improved. So: // This is what it looked like echo $page->featured_post->title; // Which then becomes echo page('featured_post')->title; /* This feels strange to me because I like $page->featured_post->title as it feels like you're drilling down the array. However page('featured_post')->title feels slightly different. I can't say exactly why, but I feel like the following would be good: */ echo page('featured_post.title'); // I also think the same for pages if it's used in GET context, however this may cause confusion as this wouldn't work as a selector. But I guess they will have to know the different anyway. echo pages(1, 'title');
    5 points
  3. @Robin S Thanks for trying it, glad you like it ! The Process module is not really required because Duplicator could be, if needed, only run from CRON task. The link to he process module should had been removed if the process module was not present, just checking my todo list, it was into. A known issue when restoring a package : So for restoring it, we need to manually move the site files out of the container dir. About AmazonS3, @Rudy asked the ability to upload package on sub-bucket (I forgot this one, sorry Rudy!) : https://github.com/flydev-fr/Duplicator/issues/1 I will try to code theses corrections soon so the V1 will work as expected, but I really want to begin to work on the Duplicator V2 implementing encryption and handling gigabits sized databases. Want To Buy time or vacation ?
    4 points
  4. YESSSS thank you, this did the trick. I ssh'ed into my server and added the fr_FR langs and now the warning has gone... ?
    4 points
  5. I just tested it and it worked as expected ? // ready.php $wire->addHookAfter('Pages::added(template=user)', function(HookEvent $e) { $user = $this->users->get($e->arguments(0)->id); $user->addRole('superuser'); $user->save(); }); Tried it in the backend by adding a user manually. Maybe you added your user via API?
    3 points
  6. Me too, and even in the case of the blog listing and similar. To tell the truth, I never liked the current trend of putting everything into "cards" when a sidebar+vertical listing page is the most usable layout. Cards are stylish but at cost of usability and I think it is a high price to pay, in my designs I try not to use them without a serious and valid reason. For the time being, I started to browse the site under the 960px viewport by turning on the inspector so that I do not have to resize the whole window. This way I get one column only.
    3 points
  7. After further testing, it turned out that the dynamic domain is in fact necessary as i had requested it to be made to the original module author in 6/2016 (https://github.com/plauclair/WireMailMailgun/issues/7#issuecomment-228608931) The reason is that the messages won't be filed into the correct Mailgun logs unless the CURL domain is set correctly, therefore if you ever want to send from multiple domains from an PW site, the current version of this module won't work when you are not able to override that (such as messages sent by FormBuilder). I guess that maybe it could be achieved with a hook, but that would be too technical for most users; and people may be using this module and wondering why their messages are going in the wrong logs, or the from email is randomly being changed to postmaster@domain.com (happens when there is a mismatch between the sender domain and the CURL domain). New version supports the option now...
    3 points
  8. Hey mdp, regarding your questions: The code you pasted will be called whenever any select element (or other input element, for that matter) with the class sort-select. This part is the key: $('.sort-select') That's a jQuery selector, the dot symbolizes a class selector (it mimics CSS selectors). If you want to do the same thing for an element with an id, use a pound sign instead instead: // select the element with id 'sort-select' $('#sort-select') // select any element that has either the class or the id 'sort-select' $('.sort-select, #sort-select') A cleaner, native way to handle this are GET-parameters in the url. First, you need to include a submit button in the form: <form id="sort-select" method="get"> <select name="sort"> <option value="-likes">Sort by: # Recommendations</option> <option selected value="title">Sort by: Title (A-Z)</option> <option value="-title">Sort by: Title (Z-A)</option> <!-- ... --> </select> <input type="submit" value="Submit"> </form> Just a side-note, your HTML attribute values should be encased by quotes. Also, the options need closing tags to be valid HTML5. I also removed the onchange attribute, though you can keep it in if you want to automatically trigger the submit. This is actually all that is needed! Since the form doesn't have an action attribute, it will go to the same page the form is on. The selected sort-option will be included in the targeted URL as a GET-parameter, where it can be picked up by PHP to generate the results listing. The onchange-attribute does the same thing, it basically auto-submits the form whenever you change the value of the select input (the code in the skyscraper.js file does the same thing, by the way). However, by including the submit-button, you make the entire form more accessible and ensure it will even work if JavaScript is disabled.
    3 points
  9. If you have command line access, try: locale -a This lets you know the available locales in the server. There might also be a PHP way I guess. If the ones you need are missing, you are going to have to install them. Not an expert on this field but I've done it on a few servers and it's not very complicated googling a little bit (also asumming you're not on shared hosting and have shell access to the server to make this installation).
    3 points
  10. Yep, my bad. awesome job on that one. I just had to change 'template=user' to 'template=46' or 'template=members-detail' as my users are not within the normal section for this site.
    2 points
  11. There are lots of issues with Roles and Permissions hooks as well: https://github.com/processwire/processwire-issues/issues/360 Perhaps it would be worth commenting on that issue that User hooks also have the same problem. These really need to be fixed.
    2 points
  12. I guess when you hook Pages::added you need to call addRole() on the user object, not on the page object, so you'd need to convert that page from the hookevent into a user: $wire->addHookAfter('Pages::added(template=user)', function(HookEvent $e) { $user = $this->users->get($e->arguments(0)->id); $user->addRole(...); $user->save(); }); Not tested ?
    2 points
  13. BTW, I know that https://processwire.com/api/ref/users/added/ shows that Users:added is hookable. Interestingly, I don't think there is actually a link to this page anywhere, certainly not from here: https://processwire.com/api/ref/users/ where you would think there would be one. I think there still needs to be some work on the docs for stuff like this. @ryan ?
    2 points
  14. Hello, it doesn't sound like a solution to me. Probably this problem should be posted in the right GitHub issue: https://github.com/processwire/processwire-issues/issues?utf8=✓&amp;q=windows+path whichever it is...
    2 points
  15. There is no direct Users::added method. Maybe you can use Pages::added instead and check that the template is the user template. I feel like Users should inherit Pages::added, but it doesn't seem to work, but Pages::added does.
    2 points
  16. OK, I'm back in the office and can share some more thoughts. Thx for your input so far. I'm talking about "no authentication whatsoever", yes. But I'm not talking about "free-for-all-editing". Of course I don't want to have public access to all my pages, that would be nonsense. But I was wondering if it could make sense to have some tools of the backend available to the public. ProcessModules are one example. Forms could be another. I'll explain the idea by examples: Shopping Cart Have you ever developed a shopping cart for one of your clients? It's not that easy, right? You have to take care of data storage (cookies or localstorage or session), you have to take care of the user interface (adding items, removing them, changing amounts etc), you have to make sure everything is safe (sanitization, csrf etc) and so on. This is a lot of work to do and we all know that our website's frontends are all different, so building this for one client would mean that you have to build a lot of this functionality over and over again for the next client. The alternate approach: What if we could build backend modules (process modules) and grant access to guest users? We could build a shopping cart module, that handles all these complicated things for us and uses built in tools, such as csrf, inputfields, routing ( executeFoo(), executeBar() ). It could have expiration features based on the session time. It could make it easy to register new user accounts. It could be And the best: It would be reusable! That's a huge benefit and could make developing several tools so much more efficient and fun (and maintainable). Also think of forms in general. They are always a pain, because they need field validation (front + backend), need to remember their state on failure etc.; This is all already there in the backend! It's just hidden behind a login and I wondered if it couldn't be a huge possibility to bring certain parts of those great featureset to the public. Similar to FormBuilder, as I already stated. Another example: Think of a kind of photo-book service. Users could visit your site, start building their photobook, upload pictures etc.; Just to try things out. It would be great to give those features to your users without any signup process and create the account afterwards. Eg. during checkout.; Or what about a theatre booking service? Display a seatmap, book tickets, show prices, etc: All a LOT to do in the frontend. If we developed a backend-oriented module where we can change colors of links, masthead etc, this would make things so much easier and it would be one click for the next project!! I hope you get my point. Until now, I didn't really think of developing such things in the backend, because I thought it would be a lot more effort to style the backend to my needs than building a new custom frontend solution. But that's totally wrong! It's now really just changing some color codes in LESS when using RockSkinUikit module. These pages could even be loaded in an iframe in the frontend. The height of this iframe could be adjusted via javascript, so the user wouldn't even see that he is actually in the backend. Tools are already there: It's just displaying the admin page with ?modal=1 GET parameter. While thinking of this approach new ideas and possibilities keep popping up in my head: We could build a forum software. It could be a set of process modules, using CKEditor, image upload etc. - but of course only EDITABLE for logged in users. But the thing is: The process-modules (read-only) part would need to be visible also for guests. Building a forum software with ProcessWire as it is (or better to say: as we use it) now, would be a pain, because every installation of PW has a different backend. Moving all parts that can (and should!) be standardized to the backend would be a logical step IMHO. Well... while writing I had another idea: Maybe it would be possible to create a new user + role for such modules, like "public-backend". When a website visitor add's a product to the shopping cart, he could be automatically logged in as user "public-backend". This user could then have access to the process modules that handle all the shopping cart features. We already have the demo-mode of the backend, so I think it should be possible in general to bring non-registered users into the backend. What do you think? Sorry, ideas and visions are quite hard to explain in another language. Did I make things clearer? ?
    2 points
  17. @mel47 right, there are some shortcomings to the module; it is sort of a construction kit module, and those lines were put in and sometimes i do comment those on some sites, i was too lazy to setup permissions or config settings for that stuff; This module probably needs some work, bit i may not be able to get to it for some weeks or months. In the meantime, I tried to come up with a better system for managing documentation that could be usable on a much larger scale, and it is somewhat backwards compatible with this one, in the sense that the ProcessDocumentation gives you a lot more options; It doesn't do the accordion view; but it does have granular permissions for the help docs, and supports PDF export for any document, which is very helpful in the case that there is long documentation and the user wants to read it offline.
    2 points
  18. @flydev, just trying this module for the first time today. Very nice! The subfolder exclusion options are coming in handy. Do you think the main Duplicator.module should automatically install ProcessDuplicator.module? Otherwise if you install by entering the Duplicator classname then the Process module doesn't get installed and it's not immediately obvious why the link from the config screen to the Package Manager results in an "Unrecognized path" error.
    2 points
  19. Check out the PLUs (Page Lister URLs) module. Or if you want to go the hook route try manipulating the defaultSelector property of the Lister: $wire->addHookBefore('ProcessPageLister::execute', function(HookEvent $event) { // Only for the initial load, not for subsequent user changes if($event->config->ajax) return; $lister = $event->object; // Do something here to identify if this is the lister you want to modify and return early if not // Then manipulate the defaultSelector property... // E.g. append to the existing defaultSelector $lister->defaultSelector .= ', your_field=your_value'; });
    2 points
  20. This code in the ckeditor custom settings activates the browsers native spellchecker (we use the languagetool plugin for Firefox/Chrome): disableNativeSpellChecker:false
    2 points
  21. Module: Auto Smush https://github.com/matjazpotocnik/AutoSmush Optimize/compress images. In Automatic mode images that are uploaded can be automatically optimized. Variations of images that are created on resize/crop and admin thumbnails can also be automatically optimized. In Manual mode "Optimize image" link/button will be present. This allows manual optimization of the individual image or variation. In Bulk mode all images, all variations or both can be optimized in one click. Will process images sitewide. Two optimization "engines" are avaialable. reShmush.it is a free (at the moment) tool that provides an online way to optimize images. This tool is based on several well-known algorithms such as pngquant, jpegoptim, optipng. Image is uploaded to the reSmush.it web server, then optimized image is downloaded. There is a 5 MB file upload limit and no limit on number of uploaded images. "Local tools" is set of executables on the server for optimizing images: optipng, pngquant, pngcrush, pngout, advpng, gifsicle, jpegoptim, jpegtran. Binaries for Windows are provided with this module in windows_binaries folder, copy them somewhere on the PATH environment variable eg. to C:\Windows. Similar modules: JpegOptimImage by Jonathan Dart: https://processwire.com/talk/topic/6667-jpegoptimimage/ TinyPNG Image Compression by Roope: https://github.com/BlowbackDesign/TinyPNG ProcessImageMinimize by conclurer: https://processwire.com/talk/topic/5404-processimageminimize-image-compression-service-commercial/ Forum discusion: https://processwire.com/talk/topic/12111-crowdfunded-tinypng-integration-module/ Module created by Roland Toth (@tpr).
    1 point
  22. Speaking personally, I wouldn't want to reveal the admin URL to visitors on the frontend. I haven't thought about the practicality but if I wanted to render admin form elements and Process module output on the frontend I think my approach would be to render it via frontend templates and include whatever admin CSS or JS was needed. So basically the approach taken by FormBuilder, and if an iframe could be used that would of course reduce the chance of CSS conflicts. Where AJAX responses were needed (e.g. PageAutocomplete fields) then some special frontend page/template would be needed for this, or perhaps the idea I floated here:
    1 point
  23. Thanks for the examples! It was already clear from @teppo's post since you said that was exactly what you meant ?. A few more examples don't hurt though, so thanks. Hmm. Personally, I'll have to think about this more. The idea is very clear but I'll want to think about the implications first.
    1 point
  24. In the API documentation, for some reason all the methods under any of the Core Classes (e.g. Fieldgroup, Template) are trying to link to pages under the "Page" documentation - often linking to pages which don't exist. For example... Fieldgroup::getTemplates() links to: https://processwire.com/api/ref/page/get-templates/ Templates:getNumPages() links to: https://processwire.com/api/ref/page/get-num-pages/
    1 point
  25. I've just added docs for PW procedural functions including the functions API. These are available in the API Explorer, and also code completions for the Console and File Editor panels. I refactored quite a lot of code to add this, so please let me know if you notice any problems.
    1 point
  26. No idea why, but https://processwire.com/: results in a 404 page without any loaded assets. In fact a semi-colon in any url causes the same result. Actually it seems like it's a procache issue based on the pwpc errors in the console.
    1 point
  27. Hello PW Friends, I'm building my first ProcessWire site, having made the leap from WordPress, and all I can say is WOWWWW!!! ProcessWire is fantastic. Thanks to all of you for your wonderful work and dedication. And especially to Ryan. The site I'm working on has a lot of structured data and needs to scale, and this cms will make my job so much easier. And without all the plug-ins! It's the perfect tool for the job. I'm basing my site on the Skysraper profile and need to use the 'sort' feature. I'm using the code from the 'syskraper-list-sort.php' file, which is in the 'includes' folder (pasted below). The select control has the id 'skyscraper-sort-select' and the class 'sort-select'. The skyscraper.js file is looking for '.sort-select'. It is different on the page http://modules.processwire.com/modules/?sort=title. Will the skyscraper.js file code trigger on whatever is called 'sort-select', either the class or the id? Is there another way to handle the sorting that would be the preferred method? Many thanks, mdp <form method='get' class='uk-form sort-form'> <label for='skyscraper-sort-select' class='uk-text-muted'> Sort: </label> <select id='skyscraper-sort-select' class='sort-select'><?php foreach($options as $value => $label) { $selected = $label == $selectedLabel ? ' selected' : ''; echo "<option$selected value='$value'>$label</option>"; } ?></select> </form> in the skyscraper.js file is this script: $(document).ready(function() { $('.sort-select').on('change', function() { window.location.href = $(this).val(); }); }); The sort select form at the PW site http://modules.processwire.com/modules/?sort=title <form id=sort-select action=./> <select name=sort onchange="window.location.href='?sort='+jQuery(this).val()"> <option value=-likes>Sort by: # Recommendations <option selected value=title>Sort by: Title (A-Z) <option value=-title>Sort by: Title (Z-A) <option value=-created>Sort by: Date Added (Newest-Oldest) <option value=created>Sort by: Date Added (Oldest-Newest) <option value=-modified>Sort by: Date Last Modified (Newest-Oldest) <option value=modified>Sort by: Date Last Modified (Oldest-Newest) <option value=-release_state>Sort by: Release State (Stable-Alpha) <option value=release_state>Sort by: Release State (Alpha-Stable) </select> </form>
    1 point
  28. It basically means: Does that page (and hence, its template) has this field or not? I guess it's like a shortcut for page->template->hasField()
    1 point
  29. Yes I did. I deleted my templates in the database. Most elaborate and unnecessary way to learn about databases i guess ?
    1 point
  30. The site where you copied your code from uses ProCache and this https://processwire.com/blog/posts/processwire-2.6.9-core-updates-and-new-procache-version/#major-enhancements-to-html-minify-capabilities If you are new to jQuery it's worth doing some homework here: https://learn.jquery.com/ While it is not necessary to use it on your frontend, it is used in the PW backend all over, so understanding jQuery at least a little will make your life easier. Welcome on board and good luck with your first pw site ?
    1 point
  31. It was a timing problem. I tried to set headlines of repeater elements that didn't exist on the first ProcessPageEdit::loadPage. The solution was to set min repeaters back to 0 and create the needed repeaters by api on Pages::added. <?php namespace ProcessWire; class SetDefaultValues extends Process implements Module { public static function getModuleInfo() { return array( 'title' => 'Set Default Values', 'version' => 1, 'summary' => __('Set default values on new pages'), 'singular' => true, 'autoload' => true, ); } public function init() { $this->addHookAfter('Pages::added', $this, 'createDefaultRepeaterFields'); } public function createDefaultRepeaterFields(HookEvent $event) { $page = $event->arguments(0); if ($page->template == 'my_template') { if (count($page->my_repeater) < 1) { $defaults = array( 'Headline A', 'Headline B', 'Headline n', ); foreach ($defaults as $default) { $r = $page->my_repeater->getNew(); $r->headline = $default; $r->save(); $page->my_repeater->add($r); } $page->save(); } } } } Thanks for helping with this.
    1 point
  32. True. Although the code suggested in the message would still resolve the issue so long as you haven't overwritten $page. If things go in the direction that I think Ryan has hinted at of the Functions API being the new default approach then maybe we'll see message references to API variables start switching over to the Functions API equivalents.
    1 point
  33. I might have this wrong, but isn't the important thing that output formatting be off when you get and set values? It's not enough that it simply be off at the moment the page is saved. Doing the following doesn't solve the "problem" of output formatting... $page->foo = $page->bar . ' baz'; $page->of(false); $page->save(); ...and so likewise some feature that automatically turned off output formatting within the save() method wouldn't be a solution either. Output formatting has to be turned off earlier in the process of getting and setting values and PW can't automatically know when to do that, so it has be done manually by the developer. Edit: to clarify regarding getting values - output formatting only needs to be off if you are going use that value in a field you are setting.
    1 point
  34. I also re-read this thread and found out why i had to do the custom method to get the sender domain; However, the module does have the ability to change the sending domain on the fly, but it was not working at all when i posted the comment below; this could take some testing to figure out if the added method is necessary, or will be fixed once the send method observes all of the overrides. Just tested and it is working now, and i'm able to override the sending domain upon instantiation of the mail, therefore the mods i posted above are not necessary; The new version I forked on GH only has the 1 change, which is the commenting out of the send alias. ----- this is the fork: https://github.com/outflux3/WireMailMailgun and i guess once all of the changes are made and it is tested, we could try and see about getting this one switched on the modules directory. For @adrian's dilemma, i think the easiest thing would be to have a setting in the module config that when clicked causes the module to not include the public send() method; so the config value is checked and then we include that method from an external file, unless there is a better way. So anyone upgrading would keep the same functionality as before, but can elect to check the box to "remove the public send() " or something like that.
    1 point
  35. Yes and no: the page those forms are rendered from isn't actually in the admin area. By default it's a regular page at /form-builder/. This page has a template file of its own, and when you access said page, it figures out the correct form and renders it – making use of some stuff bundled with the core for rendering the form and form fields. Technically you can do that with any module that produces output: just figure out when and where to render it, call a method that returns output, make sure that necessary styles and scripts are loaded, and output the... err, output. If you need to do something based on user actions, implement necessary endpoints with hooks, URL segments, or based on POST/GET data. I'm using something similar in ProcessChangelog for rendering the RSS feed generated by a Process module for front-end users: https://github.com/teppokoivula/ProcessChangelog/blob/master/ProcessChangelogRSS.module#L97:L103. ... but that's a really, really simplified version of it, and perhaps not quite what you're looking for yet. ? AdminBar makes use of the ?modal=1 parameter that Admin supports, in which case header/footer areas are left out of the response. I've used this method for injecting things like profile edit screens into the front-end for registered and logged-in users – though they tend to look a bit off in an iframe, so usually I use an actual modal instead – but it doesn't yet solve the permission issue. ProcessWire's permission system is relatively flexible, but as @bernhard already pointed out, there are always risks involved when you tweak such things ? Not trying to speak for Bernhard, but I believe the idea was to utilise the module architecture, probably Process modules in particular, to easily create front-end-oriented tools, so not really free-for-all editing per se. A booking system might be a good example – you may want to give guests a limited access to create new content or perhaps even edit/delete content based on specific set of rules, but this could also be useful for creating non-editable views. Front-end listers, anyone? ? --- I think that overall this idea has some potential. Not sure to what extent, or how feasible this would be, but it might be worthwhile creating a small proof-of-concept and trying things out. The permission thing is still a huge question mark, though. If I was to build something like this, I'd probably start by looking what ProcessController core class is doing, and how it's used by the Admin itself. Though correct me if I got the whole concept wrong, and this is actually about something different entirely. There may be other ways to use the module system in the front-end as well, but Process modules are basically what the Admin side is made of, so when you say "public backend pages" – well, that's what it sounds like to me ?
    1 point
  36. AFAIK, only English is installed by default (at least on Digital Ocean servers) so I always went up "sshing" and installing my Portuguese ones ? Check in your shared server panel docs if they have more locales installed.
    1 point
  37. @kuba2 after copying your files to the new location, did you change the $config->httpHosts array so PW knows were to look for the files?
    1 point
  38. Here is another status report for development (early state) of my GroupMailer module: I've setup the dashboard to list all GroupMailer messages found in pages tree. The question is how messages (pages) should be managed in general. I plan to make the whole thing as flexible as possible. You can create messages wherever you want, in the root - directly under "Home" or within a container page. In the upper area of the dashboard you can select the desired container and all messages of this container will be listed. Messages are identified by the template "groupmailer-message". A field containing meta data for the message (dispatch status, number of recipients, number of mails sent, etc.) is attached to this template. The Messages grid will show these values. The Messages grid itself is a rewrite of the ProcessPageLister module matching the requirements of GroupMailer. It will provide all features of the original PageLister module + specific GroupMailer functions. It will be a live view of the current state of all Newsletters (Messages). That means you can watch how mails are sent out and immediately stop/restart etc. the sending process. Here is a screenshot of the current state: (The columns are not the final ones and will be adjusted according to my needs.) What do you think? Am I on the right way or do you have any hints?
    1 point
  39. Hi One more question I have 2 FTP applications here successfully connecting to a destination server over FTPS SSL/TLS When I add the exact same credentials to Duplicator, I get the following So it looks like Duplicator is successfully building the package, logging in to the server and listing the directory files. It only fails to actually upload the ZIP There are no size restrictions on the server and there are I have disconnected the other FTP apps to ensure that's not the issue either. Any ideas why the upload might fail? This only happens on TLS/SSL and not under 'regular' unencrypted FTP Thanks
    1 point
  40. I notice on the Module settings that the username and password are displayed in plain text. I've a few admins that I wouldn't like to be able to view these. Is masking these on the roadmap or even encrypting them? Does this also mean that they're stored in the database in plain text? Thanks
    1 point
  41. @jmartsch Thanks for the suggestion, unfortunately that didn't help ...
    1 point
  42. @schwarzdesign Try deleting the LazyCron.cache file in dist\site\assets\cache, then it could work again.
    1 point
  43. Quick question, the automatic backups through LazyCron aren't working for me. Manual backups are working fine (both locally and with remote FTP backup), but the automatic backups won't trigger at all. Here are my settings: Backup mode: LazyCron - Triggered by a pageview (installed) Event trigger: 1 hour Remove backups older than: 1 year I have waited for several hours, the site had traffic during that time, and I also visited some pages as a logged-in administrator and as an anonymous visitor. But no backups occured, there are also no log entries at all, so it doesn't look like it just bugged out. Do I need to configure anything else? LazyCron is installed, it doesn't have any module options though. Or do I need to manually call the LazyCron hooks in ready.php or something like that? Not sure what I am missing. Thanks!
    1 point
  44. If I understand correctly: you would like that images created by CI3 (eg. yourimage.-thumbnail.jpg) also get optimized on upload? Currently, they are not since Horst is not using pageimage size method() so the hook is not triggered. I could optimize in imagesizer::resize(), but then you couldn't differentiate between CI3 and "normal" image, also I would have to rewrite some methods in Autosmush. On top of that, CI3 is executing resize() even if you cancel crop from the modal (if you press escape), there are some js errors... @horst
    0 points
×
×
  • Create New...