szabesz

Hello @mstroeck and welcome to the forums! What sort of server setup are you using? Any chance that you have custom rewrite rules? Any more detail that can shed more light on the issue?

I see. Yeah, far from being ideal...

Can it help in this case? 500 is an internal server error (provided it is what we are talking about) if I'm not mistaken , so it is probably a server setup issue I suppose, in which case I would start troubleshooting by looking at the Apache log file. However, I have never used this script so I might be easily mistaken.

Should you have any questions, do not hesitate to ask

@adrian's gonna love it

Not really, I'm afraid, but I have just found this one: https://github.com/gorhill/PHP-FineDiff It has an online test site: http://www.raymondhill.net/finediff/viewdiff-ex.php It generated this nice, one liner for a one line change, eg: c270d30i34: "label": "Location Eng", c583 The output of the diff tool you use is "too" verbose, is it what you do not like about it? It is probably enough to see what is different, and not the complete json string.

Thank you Bernhard for sharing it! I will take a closer look, as soon as I have some spare time. Somewhat related is my own "pet" project that I have just published here: My Bash script compares two databases. I used the changes made by your module to demonstrate the script: https://youtu.be/V6eF4NBNDbc

@pwired and all forum members I decided to put together my own bash script because I did not find what I was after. I am not a bash pro nor a linux/unix guru, so there might be better solutions using standard system tools, but I like the result so I thought I share it with you. You might also find it useful. Here is a short demo: https://youtu.be/V6eF4NBNDbc Please read the instructions (located in the script itself) if you happen try it out! Any constructive criticism is welcome. pwdiff.sh 0.0.8, (2016-10-25), initial public release:

Are you sure about this? Simply outputting a field should not prepend anything to the field's value. Can you post the exact code snippet you use?

@mel47 Hi, Just to let know know in case you are not aware of it that Adrian is away for another week or so, but I'm sure he will reply asap as soon as he is back.

@leegold Have you seen this one? http://blog.mauriziobonani.com/processwire-basic-website-workflow-part-1/ It is a four part series and fits the the step by step category.

Probably they were still recovering. Thanks!

This morning I could upgrade without any problems whatsoever. Yesterday downloading the upgrade ZIP was slow (around 130kbit/sec), today I nearly didn't wait for it. It must have been some sever issue at GitHub maybe?

I love images Really! Thanks for the update, especially for the docs, now it is high time to read it. I've been trying to follow the development, but you have added so much stuff that it is hard to keep up with you

EDIT: the problem has vanished by this (next) morning. See my report below. Hi, I have never had any issues with the Upgrades module (ProcessWireUpgrade) but currently I'm unable to upgrade to processwire-dev (3.0.38 from 3.0.36 master). I can upgrade modules though, for example upgrading AdminOnSteroids worked. I experience two different issues, depending on my MAMP Pro setup: #1 FastCGI (MAMP Pro): Internal Server error During the download process (while the file .../assets/cache/ProcessWireUpgrade/dev.zip is being downloaded ) I get an internal server error, and the admin page switches to the error page, The Apache log message is: FastCGI: comm with server "/Applications/MAMP/different-bin/php5.6.25.fcgi" aborted: idle timeout (30 sec), referer: .../admin/setup/upgrades/check?branch=dev FastCGI: incomplete headers (0 bytes) received from server "/Applications/MAMP/fcgi-bin/php5.6.25.fcgi", referer: .../admin/setup/upgrades/check?branch=dev Even though I get the error, the download process finishes and the upgrade file gets downloaded, but due to the way the module works, it cannot be used by the module next time. #2 Module mode (MAMP Pro): corrupted ZIP This time the module manages to "wait for the file" to download, but it cannot be extracted, I get the PHP error: ProcessWireUpgrade: Unable to open ZIP file, error code: 19 The strange thing is that two of my applications can extract it, but another two (one is the OS X default) report that the ZIP is corrupted. Another interesting thing is that the ZIP files I got – while testing the upgrade process several times – started to become bigger and bigger. The first time the download dev.zip was about 12MB, next 16.7MB and so on, and the last time I tried I got a 21.1MB zip file. Each of these files appears to have the same content than the one that can be manually downloaded from GitHub, even though the latter is just 10.7MB, so something is really fishy with the ZIPs I get via the upgrade module's download process. I do not have the slightest clue what is going on. Can it be a ProcessWire issue? Or something with my Mac/MAMP Pro? Or something wrong with GitHub? Note that I have not changed anything on my dev environment setup recently and also tried restarting my machine, to no avail... Normally I use FastCGI, and upgrading ProcessWire always worked with it, the last time I used it I upgraded to 3.0.36 master. Anyone having similar issues?

Unfortunately the Cheatsheet is outdated, I never use it. The new API reference (linked by @AndZyk) is up-to-date because it is generated from source code comments, and @kongondo's ApiGen is relatively new, although it has not been updated recently: http://kongondo.github.io/ProcessWireAPIGen/

Hi, "echo $entry->categories->title; //not working" Does not work, since "categories" is not a Page object, but a collection of Page objects, a PageArray: http://processwire.com/api/arrays/page/ What you need is the code snippet you used on the page but this time the collection can be accessed via $entry, because you named it as such: foreach ($entry->categories as $category) { echo "<a href='{$category->url}'>{$category->title}</a>"; }

ProcessWire 2.7.x and below to be exact. I’ve never installed PW 2.8.x, but I read that it is 3.x without the ProcessWire namespace.

Dealing with images in the admin has been completely refactored: https://processwire.com/blog/posts/major-images-field-upgrade/ So now we have "Default image grid mode" instead.

@Mackski Hi, You might want to check out these:

I'm just wild guessing here, but any chance of a misbehaving browser plugin?

I know that using a repeater for such an input looks like a bit convoluted solution, because a repeater is designed to handle more than one field "during input", but if you only assign one filed to the Repeater you use, then you can get a similar behavior. With a little bit of admin CSS hacking, you might even be able to tweak it to make its UI less "verbose" (on the repeater field's Details tab settings you can even set its items to be "always open"). Note, that without ajax loading, you might not want to create more than 40-60 items for performance reasons (depending on your server config), see: This has been improved with the “ajax option” though: https://processwire.com/blog/posts/more-repeaters-repeater-matrix-and-new-field-rendering/

Hi, What is wrong with repeaters in your case? Can you please elaborate?

Thanks @tpr, this is cool Just one more note: how about "Delete permanently!"? At this point it should be obvious what is being deleted and why is it still a question? Or am I missing something?

Awesome, thanks Adrian!