horst

I would adapt the local server to be as much equal as the production server, if possible.

Hi @d'Hinnisdaël, many thanks for this well crafted module. I (only) have read the modules code and checked some, (maybe critical) points for image modules . Everything seems to be well done! Only one thing I spotted, needs a bit clarification from you, as I may not see the whole picture yet. You added a new hook delete to Pageimage. I cannot see how this integrates with PW's methods for deleting variations. How gets it invoked when I a) delete an image via UI and b) when I call removeVariations() via the API? Or what is it for, exactly? Besides the integration with unlink & removeVariations, it may be very useful to have a function that only removes the variations from ImageOptim! TL;DR

@mscore if you think this should be included in the core module, you should send an issue or feature request at Github, to get better recognition! And many thanks for sharing this solution!

has something to do with settings of your MySQL server. The string is only 3 chars long. Try someting with 5 chars for example.

After reading this, I looked into your github page and found out that you also converted the strongly typed template. One month ago, I picked up three themes from HTML5up as starting points for low budget or honorary projects: The "Editorial", the "Strongly Typed" and the "Phantom" = 66% accordance

As far as I know, the documentation gets generated directly from code comments. For example the WireMail class: API Doc: https://processwire.com/api/ref/wire-mail/ Code: https://github.com/processwire/processwire/blob/master/wire/core/WireMail.php#L9 My personal conclusion: if you want to contribute to the docs, you need to understand the "comments markup" and contribute directly to the github code base via issues or pull requests. Edit: and also that you are now a registered forum member for more than one and a half year: Welcome to the forums!

My experiences in 15 years with PHP on windows told me to not make any (platform) differences with filesystem related stuff. Simply use the / forwardslash for everything as long as you can achieve all operations with PHP internal functions! (copy, delete, ZIP!, etc) The one and only rule where you need to convert forwardslashes to backwardslashes on windows is, when you do calls in the commandline via exec() or system(). All other stuff is handled well from PHP internallly across all platforms. So, on windows you should not use functions like realpath() or dirname() without to convert backslashes to forwardslashes afterwards! Thats the only rule I followed all the time. (locally detect windows = convert \ to /)

I'm not aware of any crossplatform differences with the internal PHP ZIP functionality. What is the issue you are speaking from? Also, I have (re)written a ZIP library in pure PHP that is only one single file. But this was in the times as the included ZIP in PHP wasn't available on many hosts.

Since early 2013, when I found PW, the lowest PHP version it needs to run on is /was 5.3.8.

Hi MrKing, if the above tips doesn't suite your needs, I can provide you example scripts of individual imports.

Ha, I'm a late adaptor in so many parts. Feels really good to be one of the early birds in this special case.

The only reason for bootstrapping in this usecase was, that I prefer this for administrative tasks. The pros are: cli access directly gives you superuser rights without extra login steps; it is very fast by copying the bootstrap script around in my local filesystem; It also works from more levels above the webroot; ... HTH to clarify. ?

I personally use a more verbose method when developing a side, as a max files may be changed during developement. // get the field unformatted, always returns an array, (not bound to context) $images = $page->getUnformatted('images'); // check if an image is available then always is via count if(count($images)) ... // get the image of a single image field always is via the first method $image = $images->first(); When switching from single image to multiple images or vice versa, always has potential to break some code. That's why I use this verbose method during development and only rework the code as a last step before deploying to public.

I think the simplest way would be to use Beas module ImageExtra , or you look into it and "borough" some code. Info: https://www.kf-interactive.com/blog/adding-custom-fields-for-images-in-processwire/

https://processwire.com/talk/topic/13759-tagging-multiple-images/#comment-123851

@Askaaron, thanks for shiming in here. You are right, I haven't read thouroughful enough the warning itself and has not go deep enough into this issue. Instead I have tried to explain the more overall behave of PW. As I use my own starter profiles with PW for years now, I never came across this issue myself. Maybe @szabesz allready does? At least he said he will add an issue report for it at github? Thanks again for clarifying on the main question.

Hi, A) it is not a problem that PW has. Every one with this meaning should have a closer look to the screen that you have posted to dropbox: The software is running without problems. It informs you, the superuser, about something language related, at a stage where it cannot know what you want to do with the site. B) It is not a bug, it is a warning or information to the superuser which is the admin. These sort of informations are never displayed to users, only to superuser(s). Superusers are some sort of bus drivers, right? They need to know how much fuel is available and if the tire pressure is to low or not. The other users don't need to know all that informations, they are not driving the bus. C) If you use a default english windows system, bought as a german in germany, and it has no de_locale settings, is this a bug? Or is it disrespectful, that it doesn't assume that the most clients may be germans and may want to use german language with german dates and german float numbers? I don't want to become nitpicking here. If a user has no knowledge of the nature of default PHP installations, how should he know that it is set for EN-locale and not DE? Does the hosting company welcome you in english or in german on their websites? (If they do in german, it is a clear sign for me that they assume you are a german person.) Maybe one can say that both ways have their pros and cons? If a PC-software informs you about a configuration of your system, that has potential to be not correct for your usage, it is one way that may help users with no knowledge about a special fact. But other then a hosting company in a special country, PW cannot "assume" the most used language there, PW is installed around the world. IMO, a hosting company may assume this, but also don't need to act upon it! It is like with a car dealer, he can buy you a car or ten cars, without to care if you can drive or have a driver licence. Should he do care? An example: If a person with no knowledge uses something two years long, without to get confronted with some facts that may need recognition or a decision, the person will have the same level of knowledge in this regard after the two years. If a person gets confronted with those facts and get pushed a bit to start to look behind the scenes of some things, he/she will have more knowledge after the two years. Is more knowledge usefull or obstructive? (You see, we are now on the floor called philosophy. ) As another example, take your own current situation: You don't understand exactly what this locale thing is or means. Is it a bug, is it an information, is it related to PHP, to PW, to something else? You are sitting between all chairs of your friend, a hosting company and some PW lovers. Not as comfortable as it could be. If you would have get some knowledge about that thing in the past, you simply would know all relevant facts about it on your own and you now already would have done some experiments with building your site. You already would have made your hands dirty with coding. IMHO, its PWs philosophy to force the (super)users into a bit more knowledge. But it is up to you, the superuser (or bus driver), which route you want to follow. Do you want to take the red pil or the blue pil? https://youtu.be/OuJ87X9YX3c?t=57 Maybe you know the SELFHTML project in germany? It's slogan was or is: Die Energie des Verstehens (The energy of understanding). It was my ever goto reference since I started with webstuff in 1998/1999. (Now you know the time when I decided to take the red one ) To sum up: Neither the hosting company is wrong, not to assume a default language, nor PW is. It's only my personal opinion when I said that it could be more by the hosting company to assume a default language, than it could be by PW. But neither the web host is buggy nor PW is in this regard. PS: Also, for me it is not a question which pil is yours. Only question for me is: Do you already have taken it, or are you just in the moment before it?

Yes, but with this articles and if you are fit in HTML and CSS, you don't need much more. Only practice. Best thing is to grab you something like from the c't article, and work with it. The few starting things you don't know on PHP you will get there and further more you will find help here in the forums. To your initial questions, it is simply HTML markup from the template files. Reading the HTML, you will find the appropriate parts and can remove them.

ProcessWire detected that this isn't set in your hosts server setting and warns you about that. I never have seen this warning on any of my 40+ projects, hosted by differend hosting agencies. And it wouldn't be a good pratice to silently change server settings, as it may have a special reason, (that is, by its nature, out of the scope of the PW installer). PW does several checks with the installer, and some more, less important ones in intervals, only visible for the SuperUser. Long story short: your host simply misses the local setting. It is the same like with your Computer System, e.g. Windows. If it wouldn't have set any locale, you may get the (for you) wrong english settings. Wrong date, time and float values, etc. etc. It is a missing PHP init setting on your (bought) host.

@fermion You may find two (or more) well written articles in the german c't magazin: https://www.heise.de/ct/ausgabe/2015-7-Websites-betreiben-mit-dem-Open-Source-CMS-ProcessWire-2562549.html And there was an article in 03.12.2016 (interessante CMS-Alternativen zu Wordpress) but cannot find it atm. Ah, here it is: https://www.heise.de/ct/entdecken/?jahr=2016;ausgabe=25;sort=seite_auf;seite=6 There are three articles in it. Better you buy the whole magazine for 4,50 instead the online articles one by one.

Hi, welcome to the forums. I think this is a good place, (at the end of the page). Unfortunately I cannot move your post to it. So, let it stay here this time. The author of the reno admin theme is @renobird.

current state: https://github.com/processwire/processwire/commit/8fe1eb13f4cbc85c6d5dad093fc559c438c92667#commitcomment-27795259 - sadly I will not have more time this week.

@Scheintod You better had asked this in the support thread of the Reno Theme. The author may have checked to get notices of follow-up posts.

There are no such steps. The cropable image and the focus point are completly different things and can be used side by side. If you want to drop cai and use focus point, you have to switch the api code in your templates. Before you completely remove cai calls, you may change them to a call to remove variations. But others then that isn't necessary.