Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 10/13/2016 in all areas

  1. Hey everyone, Max from Snipcart here! We just published a full tutorial showing how to use ProcessWire + Snipcart (our dev-first HTML/JS shopping cart platform) to enable e-commerce. It was pretty much my first time playing around with the Apache/MySQL/PHP stack, so I'd love to get some feedback on the demo code. Oh, and also, if you feel like the Snipcart integration could have been done in a different/better way with ProcessWire, let me know! > Blog post tutorial > (Very) simple live demo > GitHub repo Cheers folks.
    7 points
  2. I've created a git repository for this useful little module here. Fully attributed (in the module) to ESRCH.
    6 points
  3. Hey guys, I am working on a Visual Studio Code Extension which contains snippets for the Processwire API. You can see my WIP in my repository: https://github.com/jleifeld/Processwire-API-Snippets-for-Visual-Studio-Code It is much work to do everything by hand. Is there a database for the api which contain the same documentation as in the PW cheatsheet? This would make the work easier and faster for me. Thanks, Jannis
    3 points
  4. Or, even better since it avoids a roundtrip through the database, would be Pages::cloneReady, which is called after the page is copied in memory and before it is saved to the database. Usage is the same, sans the call to $newpage->save(). I'm using Pages::cloned in my module because I need the ID of the new page which is only available after it has been saved.
    3 points
  5. Yep, GD-lib doesn't support any Image-Markers. Every thing get stripped. But in times where everyone tries to decrease page- and imagesizes, I think this is good. You always can access the EXIF of the original image. And to be consistent across different ImageREnderingEngines, the default is to strip all markers, but not IPTC(!). That's because IPTC will not be available in an image until someone has explicitly added it, not like with EXIF. @tpr: thanks! And yes, this is known to be an issue. It is an issue of the croptool(s). I remember that there were dev testing from Ryan and others, on how to solve this. But until know, nothing went into the code base. Every visually editor, like the crop tool or CroppableImage3, should detect the needed orientation correction and behave accordingly. ATM, all of those tools display the images uncorrected, determine the correct crop positions and dimensions, pass that to the imagesizer, imagesizer first detect wrong orientation and swap width / height but not for the passed crop positions / dimensions That results in totally wrong crops. What we need here is a standardized way to A) display wrong orientated orig. images corrected via CSS or JS in the cropping tools, B) a calculation function that can swap those "wrong" calculations to apply correct for orientation corrected images. Should this calculation be called by the cropping tools, before they pass the positions to imagesizer, or should they simply add a flag to show imagesizer to apply that calculation too with the orientation correction? A year back, I have experimented a bit with CSS transform: rotate(90deg), but lost the focus on it.
    3 points
  6. v077 is up with some minor updates to InputfieldURLChecker, pageListIDs, FieldEditLinks and Hotkeys. The latter is the smallest but I like it the most because it fixes the malfunctioning ctrl+s in CKEditor after editing the content in the Source dialog. This will probably fix all similar cases when the CKEditor content is replaced (eg. by a plugin).
    3 points
  7. Just wanted to let you know you guys know that there have been a few tweaks to the console panel of late - nothing major, but improvements to error handling, and also notes that say "Processing" and "Completed" so you know that your script is running and when it has completed which is very handy when you are running a script that manipulates content, but doesn't output anything. I was also just reminded of the outstanding issues with the AJAX bar and the PW SessionHandlerDB module - I was testing something on an older site (built when I used to install SessionHandlerDB as a matter of course) and couldn't figure out why bd() calls from the console panel weren't triggering the ajax bar to load. I usually use d() from the console panel so the results are right there and you don't need to refer to the dumps/dumps recorder panel, seeing the bd() reminded me that it's still not sorted. Anyway, just wanted to remind everyone who uses SessionHandlerDB about this in case you didn't know / forgot like I did
    3 points
  8. Ok, I have committed the new version. A huge thanks to @horst for contributing this functionality. Here are the key new sections to the module config: @Christophe - just pinging you to make sure you see this new functionality.
    2 points
  9. Forgot to mention: unless I hear otherwise from ESRCH (I've messaged) I plan on pushing this to the module repository as it's so useful, it needs to be in there from someone. Anyone.
    2 points
  10. If possible, before uploading an image open your browsers dev tools and check out the Network panel (or something similar) in there. When the upload starts, you should see an AJAX request. Still in the dev tools check what the response part of that request looks like. If you see an error message there, that's the culprit (and the error message will likely tell us what exactly went wrong).
    2 points
  11. Ok, thanks, I was remembering this thing wrong. In the announcement blog post reads that So it works only after opening the image edit panel. https://processwire.com/blog/posts/major-images-field-upgrade/
    2 points
  12. I don't think/remember that dragging an image on another one will replace it. Do you mean with a different name? Usually I just add the image. By default, it renames the new image file if the filename already exists (like adding "-1" or something else). If "overwrite existing files" is checked, it replaces it. Normally, but I could be wrong, you cannot replace automatically an image with a new one (with different filenames) just by dragging it on top. When there is only one image authorized in an image field it can make us think that this is what happens. If the filename is the same it could be that it renames it also by default, as the old image hasn't been removed and the page saved before adding the new image.
    2 points
  13. I think this is a PW issue in general. I think there has been some discussion on it (but can't find it right now), so I am not sure why it was decided to not support utf8 filenames but that was before PW supportedUTF8 page names, so maybe it is time to revisit?
    2 points
  14. Looks like all you're missing is InputfieldPassword.css.
    2 points
  15. @arjen When I was looking 2 days ago I couldn't find it either. @BitPoet I agree. In the docs it says only sort order not index and we can use some PHP to get the index. This code works for me: foreach ($homepage->children as $key => $child) { $sortIndex = $key; // or $key + 1 if you don't want to start with 0 }
    2 points
  16. One thing I did on a past site was to get a database copy from the live site, restore on a local machine, do all the stuff locally then restore. I had around 20,000 items I was importing and ran into timeout / memory issues. I was also pre-processing images which was helpful as I was able to upload those as well. My current server sometimes eats up the ram due to image variations for large images but I currently run that site on a server with 15gb. If this is a one time deal you may be able to think this way, otherwise there might be some more server / php / apache memory settings you can tweak to get usage down.
    2 points
  17. After seeing your ode, the solution @kongondo pointed at doesn't really apply here because you're not creating a page array, but looping through the data that comes from the API. Any reason why you're not using the same variable to create a page, and to add the fields and save? You would spare a call to the database on each iteraction if you didn't: $page = wire('pages')->get("parent={$parent_page->id}, this_id={$page['id']}"); // where this_id & $page['id'] are this entities id in the api if(!$page->id) { // CREATE new page $page = new Page(); // <- removed the $new_page variable ... // Some generic fields // save $page->save(); // not needed -> $page = wire('pages')->get($new_page->id); } ... // Set some more fields based on API data // save $page->save();
    2 points
  18. @BitPoet I owe you an apology. I hadn't turned debug off properly. Once I did that the memory usage held between 25Mb and 40Mb. A drastic reduction
    2 points
  19. One of PW 3.010's major novelty was the introduction of Horst's new image resizing engine that uses ImageMagick. Now I understand that ImageMagick can convert images to Webp, the image format that Google says can reduce image size up to 34% compared to JPEG. Mozilla is apparently adding support to Firefox, and even the Safari team is playing with it, so it looks like Webp is soon going to be available in most major browsers. If Horst's module can be extended to add Webp conversion, that would be a great addition to PW's already very powerful image manipulation arsenal. I'm currently using the free ImageEngine Lite to serve Webp images to supporting browsers, and the results are impressive. I routinely get images that are between 25 and 60% smaller compared to JPEG, with the same visual quality. I would love to eliminate the need to rely on a third-party service though.
    1 point
  20. Yeah, that's essentially what I have done. Any thoughts/experience with this: http://www.nurkiewicz.com/2015/02/retry-after-http-header-in-practice.html What clients do you think they are referring to? I would have thought that search bots might be triggered by this, but doubt they would all hit it immediately at the Retry-After time. As for manual users - that is unlikely also. I guess I could randomize the Retry-After time somewhat - maybe at 1 minute intervals for up to 10 minutes after the entered time, but it sounds like overkill for almost all sites. I'll ignore unless you have any strong thoughts on it.
    1 point
  21. On a site that is always protected, it simply doesn't matter. But on a site, where I regularly only use some single protected pages but a big part is publicly accessible, there it is better to use SEO friendly headers when closing the whole site. It is important for sites that are already indexed, and temporarily are not accessible. That's why you thought it belongs to Petes module. But when I already have installed ProtectMode and it can close down the whole site, I have maintenance mode already, or not? Maybe best solution would be to offer both methods for the root page? Radio or something else for: protect | maintenance, plus a datetime via showIf for maintenance?
    1 point
  22. I think, sending a 503 and "retry after" should be done everytime if the whole site is closed / protected, regardless if you call it protect mode or maintenance mode. This is important for SEO. I think both of the modules, yours and Petes, should do that by default, when the whole site is not accessible for SearchEngines. (just my 2cents)
    1 point
  23. updated my post above with the zip. It is an early version that I set to 777, to avoid overwriting with updates of the original module. I also must have one version somewhere in use, where the estimated end date is reflected in the user readable message at the login screen too.
    1 point
  24. Hey @horst - I am happy to add that functionality to this module, but I guess I thought it belong more in Pete's module, but if you guys would rather see it here, that's fine with me. Do you feel like sending me a PR? Otherwise if you post the zip, I can grab the relevant bits and incorporate.
    1 point
  25. @Christophe, once I have hacked a module (in an early version) of adrian to add exactly what you are looking for. GET http://fua.pw.nogajski.de/ [HTTP/1.1 503 Service Temporarily Unavailable 187ms] Date: Thu, 13 Oct 2016 20:14:54 GMT Retry-After: Sat, 22 Oct 2016 11:22:00 GMT So, if you like, I can upload it here as is, in a zip. Maybe, @adrian gets inspired and can add this into the current dev of his module as a maintenance feature, additonally to the site protect feature!? very old, hacked version of protect with maintenance.zip
    1 point
  26. Thanks! I've added patches here and there when I found something odd or when you guys here reported something. There will be always issues with this module as it's basically a collection of many small modules covering many areas, leaving room for potentional bugs. Anyway, I feel a bit lost without AOS in the PW admin - of course the module is mostly designed to fit my needs
    1 point
  27. @tpr I tried this module out when it was a very little baby and ended up removing it as there were too many layout quirks when used with the Reno theme (which I use by default.) I re-installed it yesterday to find that it's grown up very nicely! It's now in three installs and probably heading for more. Thank you for this module! I'm also about to try out your MarkupSrcset module - but that's off topic here.
    1 point
  28. @adrian & @ukyo: I'm not aware of any upload processing done by CroppableImage3. It only extends the coreimage field in some points, but nothing in regard of uploading.
    1 point
  29. And this too http://processwire.com/api/ref/
    1 point
  30. Hi @benbyf, just wanted to let you know that I'm moving this topic to the Module/Plugin Development subforum. If I'm mistaken and this is indeed a module support thread, we can always move it back. Thanks!
    1 point
  31. Thank you Adrian for the clarifications/confirmations. I'm going to ask Pete.
    1 point
  32. Sorry for early post before check console errors. Its look like error causing from Croppable Image 3 module. When i check ajax request there is an error: Notice: Trying to get property of non-object in /website/site/modules/CroppableImage3/InputfieldCroppableImage3/InputfieldCroppableImage3.module on line 139 File: site/modules/CroppableImage3/InputfieldCroppableImage3/InputfieldCroppableImage3.module $attr['data-image'] = $pagefile->getCrop($suffix)->url; I think the module can't get data, because name is changed. Here is custom upload names module filter settings :
    1 point
  33. Since we're talking modules, one needs to use a relative or dynamically assembled path, and make sure that it doesn't break when FileCompiler comes into play. Thus, if the class is only to be used by the module itself or by code that explicitely references the module, adding it to the module's file is IMHO the most reliable approach.
    1 point
  34. Maybe the APIGen from Kongondo helps a bit... https://github.com/kongondo/ProcessWireAPIGen And there are snippets from sublime regards mr-fan
    1 point
  35. The server software looks good. I would select PHP 5.4.x or higher. Upgrading to PHP 2.7, the legacy Version at a first step should be relatively safe, depending on the third party modules you run into that site. Can you post a list of all installed and used site/modules ? Regardless of that, you first should backup a mysql dump and the complete site folder! If you can, you than should install (locally?) a copy of that site and test the upgrade there. If not, it is also possible to do it on the live site, if you: can set it into maintenance mode some how have an external access to the mysql DB for backup and restore operations
    1 point
  36. Sorry for rising this topic from the dead, but I'm facing the same problem currently. I would like to add a custom option to a module, which allows to upload an image. Since a module is not a page, you simply can't bind an image to a module, I guess. Is that assumption right?
    1 point
  37. It's already like this in the installer sql script, so it shouldn't be much trouble to change the property for all pages with parent 1. I wonder, though, in which circumstances this would be an issue, since the sort order is still correct. So if anything, I'd regard this as a feature request and not a bug. Just my 2 cents.
    1 point
  38. @szabesz: I updated the code examples.
    1 point
  39. You have set private $userName You can set it to public, but only for fast testing, but better: use the magic get method as I showed you in my first post above. You cannot access a private property from the outsite. The function that receives the Event is "the outside".
    1 point
  40. Thanks already altered the core code, but i am going to inform the client that disadvantage of not taking emails... really requests like this make me want to quit frontend and do Backend totally.
    1 point
  41. Well, turns out it was a hosting problem. The account wasn't properly configured and ran out of space
    1 point
  42. TracyDebugger - use the Dumps Recorder panel and if you have to, use the "Preserve Dumps" checkbox (although you probably won't need it). Then insert a bd($var) call into your code - easy as pie PS Who uses var_dump anymore
    1 point
  43. Could you try... $hp = $event->pages->get(1);
    1 point
  44. Thanks @arjen According to this thread and Soma's post here it should work. But I'll try your code or a foreach($homepage->children as $key => $child) {} and post back results here.
    1 point
  45. Does $page even have a sort property? If you want to get the index of the $child you could also check its position in the PageArray using getItemKey(). Something like this: $children = $homepage->children; foreach($children as $child) { echo $children->getItemKey($child); }
    1 point
  46. Okay, thank you. If someone is interested, I have updated the MarkupSitemapXML plugin to ProcressWire 3+ https://github.com/keksmampfer/ProcessWire3-MarkupSitemapXML
    1 point
  47. Just for your own clarity, it might be better to use addHookAfter, because addHook can actually be used to add your own method to a class. https://processwire.com/api/hooks/
    1 point
  48. i'm still voting for a solid and core solution of image cropping. using either an exact crop, or predefined ratios, or using a focus area and make it possible to get the right image for the right spot on your template/design and allowing different ratios! but i guess we 2 are in a minority... ?
    1 point
  49. Hi kongondo, Thanks for the quick reply and the welcome. I had actually already read the topic that you mention, and this is what prompted my need: I would like to save a "stock" field for each product, but this field would have to be calculated each time a stock movement is saved, and calculating this field is precisely what takes so much time. In the meantime, I continued looking into the problem, and I think that I came up with a solution with the following module: class PagesSum extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'Pages Sum', 'version' => 1, 'summary' => 'Adds a $pages->sum($selectorString, $fieldName) function to sum the value of a specific field over a list of pages selected by a selector string.', 'singular' => true, 'autoload' => true ); } public function init() { $this->addHook('Pages::sum', $this, 'sum'); } public function sum($event) { $selectorString = $event->arguments(0); $fieldName = $event->arguments(1); // Find all the pages associated with the selector string $pageFinder = new PageFinder(); $idQuery = $pageFinder->findIDs(new Selectors($selectorString), array('returnQuery' => true)); $idQuery->set('orderby', array()); $idQuery->set('groupby', array()); $idQuery->set('limit', array()); $stmt = $idQuery->execute(); $idArray = $stmt->fetchAll(PDO::FETCH_COLUMN); // If no pages were found, return 0 if (count($idArray) == 0) { $event->return = 0; return; } $idString = implode(',', $idArray); // Get the table name for the given field name $field = $this->fields->get($fieldName); // If no field with this name is found, return 0; if (!$field) { $event->return = 0; return; } $tableName = $field->getTable(); // Run the SUM query $sumQuery = new DatabaseQuerySelect(); $sumQuery->select("SUM(data)"); $sumQuery->from($tableName); $sumQuery->where("pages_id IN ($idString)"); $stmt2 = $sumQuery->execute(); list($total) = $stmt2->fetch(PDO::FETCH_NUM); $event->return = $total; } } In my tests, it is about 60 times quicker to calculate the sum with the function $pages->sum($selectorString, $fieldName) than looping over the pages (for about 12000 pages). I would appreciate any feedback, in case there are any other optimizations to be achieved, or any errors I haven't thought about. And I hope that this might maybe be useful to others too!
    1 point
×
×
  • Create New...