Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 09/16/2021 in all areas

  1. Hi Ben, This took me a bit to understand, but I think you're looking to generate an OpenGraph image similar to how GitHub's OG images appear to almost be an HTML page converted to an image? (At first I thought you just wanted to use a template to assign a specific page image and generate the meta text...) Chris Coyier at CSS-Tricks wrote up an overview of a couple different ways to produce something like this. His platform is WordPress using GD, but it could just as easily be applied to ProcessWire and IMagick. There are also services out there to help with this as well. See the comments for even more info. https://css-tricks.com/auto-generated-social-media-images/ I'm in the middle of cleaning, patching/repairing walls, and repainting my guest room after a "friend" destroyed it on me, otherwise I'd offer to get a quick example going for you over the weekend. However, your needs are likely custom to your project and there are any number of various ways to produce this, so hopefully the overview linked will give you a good head start! ?
    3 points
  2. ..., yep, ooor, you should not use ../ this in your dest path. ? This is for security reasons. If you give real $dest pathes without up-traversal segments into your createDuplicateImage() function, then you don't need realpath() there. Or you use it one step earlier: public static function createDuplicateImage($src, $dest) { if (file_exists($src) === false) { return false; } // NOTE new line $dest = realpath($dest); // Duplicate the file \ProcessWire\wire('files')->copy($src, $dest); return new \ProcessWire\ImageSizer($dest); } But anyway. I'm glad you figured it out and finally it is working for you! ?
    2 points
  3. @arweb I had the same error recently. How to fix it: rename FieldtypeTextareas folder in the site/modules to .FieldtypeTextareas install the latest version of FieldtypeTextareas (8a is the latest) To prevent future error, simply update FieldtypeTextareas to the latest version prior to upgrading the core.
    1 point
  4. Hi I found ! Two pages references with a selector all pages... It was a mistake. Simple and done ?
    1 point
  5. Moderator note: this is not a module support thread, so I'm moving it to the General Support area of the forum instead. Please keep in mind that the Modules/Plugins area is only intended for module-specific support threads. Thanks!
    1 point
  6. it must be something like this. we have not had this problem before. The thing is that the server is already set to imagick. So I guess there is no other way but to fix the images accordingly. Thanks a lot!
    1 point
  7. Yep. I bet that this are 99.9% transparent pixels from the originals cutout pictures. I mean the originals were photographed on a more or less white background, then it get cropped not by a hard pixel path but by some tool that uses cropping by transparency mask. After that, a shadow drop was added. In the original images the cropped out area is visually not seen, but there are some pixels with a special setting: color white & transparency 100%. It would have been better, if the cutout had be done by hard cropping, 1-2px into the object. If this currently is resized by GD-lib (PWs default or fallback engine), you may try to switch to ImageMagick engine if the server allows this.
    1 point
  8. Thanks for confirming. Another problem solved on this great forum. ?
    1 point
  9. Thanks. I have found out the issue and it was not permission-related. In file-errors.txt I had this error: allowPath: pathname may not traverse “../” I don't really understand how it works but from looking at the source is seems WireFileTools->allowPath() is blocking it. This fixes the error: public static function createDuplicateImage($src, $dest) { if (file_exists($src) === false) { return false; } // Duplicate the file \ProcessWire\wire('files')->copy($src, $dest); // NOTE new line $dest = realpath($dest); return new \ProcessWire\ImageSizer($dest); } You need to call realpath() after file duplication (since realpath() does not work on non-existent files). This sends the full canonicalised absolute pathname and WireFileTools via ImageSizer deletes the -tmp files. I'm not sure if this is intended behaviour but I hope that helps anyone else who needs to do this. I presume it is a security feature that blocks certain paths from file manipulation.
    1 point
  10. This must have to do with the access rights set in your server setup. Normally they get set via wirechmod($filename) automatically. ?
    1 point
  11. Hi, i have some bad news that i personally consider as good news ? the short answer is... no well, i could quote one on sell at codecanyon, the seavuel hotel but, honestly i would strongly advise you not to use it even if you could want to buy it, install it and have a look at how things are done PW gives you exactly the opposite way of working than wordpress, you just install sort of a frameworks with a fantastic CRUD admin even this admin, you'll have to build the one you need with the fields you need and only those, the templates you create and pages to which you'll attibute those template, and so on this makes you think the right way, you website is unique and so will be its back-end i have made two restaurants websites with PW (https://www.restaurantilgrano.com/, https://www.restaurantlafamiglia.com/ ) for the same company/owner but starting each time with a blank site helped me not to try adapting the website to the CMS and a theme but adapting the CMS to what i needed and that is all PW is about i understand that, at first, it may sound like more work to do but, soon, you'll find out it's far less heartburns to come ? do have a try at it, you won't regret it ? have a nice day
    1 point
  12. This week there are a few minor updates on the dev branch, though not enough yet to bump the version. The most notable are a few improvements to the database selectors you can use with $pages->find() and similar API calls. While working through issue reports a few weeks ago, there were a couple issue reports that indicated one selector or another not working. What I found was that it was working as designed/built, but they were just selector features that had never been supported. But they also seemed like good/useful shorthand syntax to support, so I was enthusiastic to add support for them. I just wanted to wait till we were back on the dev branch, as we are now. Here's what's been added: Support for OR values on "status=" selectors. Now you can match one status or another with PageFinder selectors by specifying a selector like "status=hidden|unpublished", and this will find all pages that either have hidden or unpublished status. The hidden and unpublished are just likely the most common examples, but you can use any other status name, or as many statuses as necessary in your OR condition. Previously it was possible to match pages having one status or another by other means, but it was far from straightforward. Now it's nice and simple. Support for OR values on "sort=" selectors. This one isn't technically an OR condition since we are giving a command to the selector engine about how it should sort, rather than trying to match something. You can tell it how to sort with the syntax "sort=date|title" as an example. That would be shorthand for "sort=date, sort=title", which is saying "first sort by date, then by title". Support for combined start and limit selectors. Previously you have had to specify "start=x, limit=y" separately, if you needed it. Now you can optionally specify both as part of the "limit", for example "limit=5|10" which is shorthand for "start=5, limit=10", and actually kind of similar to what it translates to in MySQL, which is "LIMIT 5,10". I suspect that not many people ever use "start=" in their selectors unless using "start=0" to prevent a set from paginating. So if you wanted a set of 10 pages that don't follow the current pagination, you could specify "limit=0|10" in your selector, or the more verbose "start=0, limit=10" will work in any PW version. Support for matching children paths. This is a small one, but previously you couldn't do "children=/path/to/page" to match a page having the given child path. Though you could do "children=123" where 123 is the ID of the child page. It has been updated so that it can now support paths in addition to IDs, just as "parent" does. I'm not sure why we didn't have support for this one before, it likely just hadn't come up yet. You can use OR values here too if you'd like. As before, you can also use subfields on "children" as well. Worth mentioning is that these are additions for our PageFinder engine which queries the database. We also have the lesser used in-memory selectors which don't yet support all of these, but I've put it on my to-do list. In-memory page finding selectors come into play if you are post-filtering pages that you have already loaded from the database into a PageArray. We like these to maintain some consistency with the database selectors when possible, so I'll likely have that working here soon. From this end, I'm also putting ~2 hours of work into the new Pages Snapshots module every day, with a lot of progress but also still a lot of ground to cover. Separately, I'm working on pulling more than 4 million articles out of an older proprietary legacy CMS for a newspaper organization and converting them to a standard XML format for import elsewhere. A lot of data conversion has to take place in terms of cleaning up markup for each article. ProcessWire is the tool that all of this is being done in, and I'm using a lot of $sanitizer methods as well as keeping HTML Purifier busy! Thanks for reading and have a great weekend!
    1 point
  13. Hi @Sebi your module is of great help, we are using it in quite a view projects allready. i just build a mobile app with a processwire backend using Double JWT. While implenting it i noticed the following: In the docs the /auth route is described to be used like this (in addition to basic auth): // Alternatively you can send username/pass in the request-body: this.httpClient.post( 'https://my-website.dev/api/auth', JSON.stringify({ username: username, password: pass, }), { 'x-api-key': 'ytaaYCMkUmouZawYMvJN9', } ); but this does not work for me. It actually works with basic out and also when sending username and password as form-data. But not as JSON. Its no big deal with two working alternatives, but it would be actually nice to have the JSON option also (specially since form-data can be challenging to set up with some http-clients. I allways get the following error with the above call: { "username": null, "pass": null, "post": [], "test": "{\n\t\"username\": \"REMOVED\",\n\t\"password\": \"REMOVED\"\n}", "errorcode": "general_auth_exception", "error": "Login not successful" } Best, Michael
    1 point
  14. Another handy update on v1.0.19 ? map(column, labels) Sometimes the value stored in the DB is a key that is not as descriptive as a text label. For example it could be that the returned value of a "sex" column is f for female or m for male. One option is to replace this value via JS which could have benefits regarding performance on large datasets, but it is a little more work to make everything work as expected (eg you need to take care of formatting of the cell as well as the sort and filter values). It might be easier to map the returned value of the finder to an array of labels in such cases: $sexes = ['f'=>'Female', 'm'=>'Male']; $rockfinder->find(...) ->addColumns(["sex", ...]) ->map("sex", $sexes); The column will then show male and female instead of m and f.
    1 point
  15. I think you both have valid points. If ProcessWire wants to get more exposure and usage (…more devs creating quality modules) there are lot's of places to advance or update documentation or educate better. Especially module development can easily be daunting to newcomers as it's basically "do what you want" besides some conventions around config / module info / process module callbacks. There could also be more (UI) components to make processwire modules really feel like integrated into the backend. Currently this is mostly on the module developer which is neither efficient nor works really well. Besides the InputfieldWrapper and MarkupAdminDataTable component I feel like there's a severe lack of consistency in the ProcessWire UI a.k.a. truely reusable UI components to be used by module devs. One can certainly do a lot with just those two, but that depends on the module. It should be perfectly fine to talk about such shortcomings. Especially if it's the experience of someone new here it should be a clear sign about places to improve. What we should be aware though is that we're still talking about oss and resources are sparse. Ryan will do what he can in the places he thinks are most important. This might not necessarily align with what other people think is most important. E.g. from my years in this community I feel like Ryan sees ProcessWire much less as a CMF than many people use it as. So the developer turning the admin experience around by 180 degrees is not really the primary target group. This explains any lack of grand documentation in this place and maybe the quite a few modules needing to fill in the gaps.
    1 point
  16. Thanks for your help. I used Ryan's suggestion of starting the path to my includes with "./" <?php include('./includes/footer.inc.php'); ?> Worked like a charm.
    1 point
  17. I would suggest grabbing one randomly from each page: $entries = $pages->find("template=gallery_entry, sort=random, images.count>0, limit=6"); $images = array(); foreach($entries as $entry) { $images[] = $entry->images->getRandom(); } foreach($images as $image) { $img = $image->size(80,60); echo "<a href='/albums/'><img src='{$img->url}' alt='Latest photos' /></a>"; }
    1 point
×
×
  • Create New...