• Content count

  • Joined

  • Last visited

  • Days Won


horst last won the day on April 23

horst had the most liked content!

Community Reputation

3,878 Excellent

About horst

  • Rank
    observer of the big picture
  • Birthday 11/05/1955

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
    Aachen, Germany
  • Interests
    Photography; PHP, HTML, CSS (SASS,LESS), JS;

Recent Profile Visitors

28,880 profile views
  1. module

    Here are the latest "official" notes ------------------------------------------------------------------------- Updating from prior versions: Updating from Croppable Image 3 with versions prior to 1.1.7, please do this as a one time step: In the PW Admin, go to side -> modules -> new, use "install via ClassName" and use CroppableImage3 for the Module Class Name. This will update your existing CroppableImage3 module sub directory, even if it is called a new install. After that, the module will be recogniced by the PW updater module, what makes it a lot easier on further updates. ------------------------------------------------------------------------- Sticking with a PW legacy 2.8.20+ Version (none namespaced)? - I have created a CroppableImage2 snapshot, which you can get from the github repo branch: CroppableImage2 -------------------------------------------------------------------------
  2. module

    @Robin S, please can you test an update from an installed version prior to 1.1.0? I have updated the github repo to 1.1.7. The first "update" has to be done by installing via ClassName in side -> modules -> new: Module Class Name = CroppableImage3 It has worked for me this way. Existing directory was changed / updated with all new files, old unused files were removed. And now, after that, it is recognized by the updater module! Yeah!
  3. module

    I will test that again later on, thanks Robin!
  4. module

    Due to less time, I will wait until the UIKit Admin is official / stable, before trying to locate and fix incompatibilities. But any pull request is welcomed.
  5. module

    That's what I made in Version 1.1.0: https://github.com/horst-n/CroppableImage3/commit/6a52e7726170bf3d81981c1d0da9cc247bbaa1b0 ------- Ok, your test was on a first install of the module, and not as an upgrade, yes? How does it work out for those who have installed a version prior to 1.0.0? Thats the most common and important situation! You have installed the 3 modules, each in its subfolder or not, but Fieldtype... is the main module, than you use the update module button, (you will need an existing wrapperclass CroppableImage3.module in the github repo for this to work!). <= Thats what I have tried already and it hasn't worked for me. Always left one dependency uninstalled. But I will try this once more, as 1.1.6, - just to check if my test with 1.1.0 / 1.1.1 wasn't interfered with another issue that made it broken. Many thanks for your support @Robin S !
  6. module

    Was allready done. It resulted in not correctly installing all needed dependencies (with a wrapper class: three). It only installed two out of three, then complaining about the missing one. System broken!
  7. module

    Hey, this is a follow up from here: So, now I have tested every possible combination from ClassNames, filenames and the ModuleName. Every thing will break something when used from an allready installed module with an upgrade through PW. When I define the main classname in the modules directory as FieldtypeCroppableImage3, the update process fetches the repo, but installs it under site/modules/FieldtypeCroppableImage3, whereas the existing repo stay under site/modules/CroppableImage3! This breaks the whole site, front and backend. The updater doesn't rename the origin repo with a leading dot. Other solutions tested also broked things. So, can you please tell me which way to go to bring the module into recognition of the update process?
  8. module

    How did you install / update it? Update a previous version or first install? manually or via backend or ...?
  9. Module

    The reason it wasn't detected was, that no module was in the root directory of the module, but all each of the three modules resides in its own subdirectory.
  10. Module

    @Robin S it was due to an needed upgrade from Pim1 to Pim2 because of changes in the naming conventions for images in PW > 2.6.?. At this time Pim1 already was installed and used in many sites. When people upgraded their PW version in those sites, they could not / cannot simply change Pim1 with Pim2. There was a manually action in changing API calls in template files needed. This was / is the reason for this weird behave. For the simply case of first install of the module, I can use a PW version detection of course, but that wasn't the problem. The problem was / is, that in prior PW versions with use of Pim1: i must used the Pim1 as first / only module, to get the people informed about update changes via upgrade-module(s) must ommit an automated change from old naming convention to the new one, because sites possibly would break down if I would raise a need to recreate every image (!) So, yes, I was and I'am very unhappy with this situation. If someone has a better solution, please tell me. ------- BTW, with the CroppableImage3 I run into something similar: Croppable3 isn't recognized by the widely used upgrade-module from Ryan, so people don't get informed about updates of it. I believe, many sites are running a version prior to 0.9.17. Everytime someone updates an older PW version site to a newer version, they run into a bug that was already fixed a year ago in version 0.9.17. People than always report that they just upgraded from x to PW > 3.0.31* (or similar), and the module now wouldn't work anymore. But it is already fixed. They all need to do a manual update, but how can I inform them? The updater should do so, but doesn't do.
  11. Have you disabled or refreshed browser caching? Have you checked the files in local and or FTP directory? or do you only noticed this "not changing" in the website by using the browser?
  12. I used it at least here: https://nogajski.de http://joerg-hempel.com http://bella-italia-aachen.de/
  13. @jploch: a question from me to clarify: You have installed ImageAnimatedGif module and it produces correct resized and animated variations with calls to pageimage methods (widt, height, size), but it doesn't produce the same result when you use it with MarkupSrcSet? The ImageAnimatedGif hooks into before pageimage resize, and MarkupSrcSet simply calls pageimage size, so I'm wondering what could be the difference here? What is the result of MarkupSrcSet? Images are scaled down and animated, but with artefacts? Can you provide an example? (a variation from direct call to pageimage and one result from MarkupSrcSet)
  14. It seems to be wrong as you call wire() in the global namespace, but you must call it in ProcessWire namespace. What you do is calling \wire(), but it must be ProcessWire\wire(), what would be really weird to add it with every call to a PW function (in a PW programm). Best way would be to add the namespace on top of each *.php file in your template system, (template file, view files, snippet files, ...): <?php namespace ProcessWire; Than it should be valid and functional.
  15. @rick: In your code that handles the form input, you simply can call the module or public module method: //if(<condition for form was posted>) { $myModule = $modules->get("MyModulesName"); // get a module handle $myModule->passNewDataIn($input->post->someData); // call the public method for data input // rest is done in modules method, ... // if you are not in template scope, you can use $myModule = wire("modules")->get("MyModulesName"); //}