Leaderboard

Unless set to "1", image fields return an array (as do File fields, and many others). You have to either foreach through all images, all call a specific one. You can do: first(), last(), or eq(n). Read more about it here: https://processwire.com/api/fieldtypes/images/

For a little more info on what I found which will hopefully help others: There were lots of JS errors in the browser developer tools Console tab like this: Uncaught SyntaxError: Unexpected token < which is a good indication that there is an error message, or at least some HTML being returned in the AJAX request which is not expected by the JS script. So then I went to the Network tab of the developer tools and found the script that is uploading images (?id=1&InputfieldFileAjax=1), and checked the response - that is where I found this login form: Also. of course, when I saved the page, it asked me to login again, so that was also a hint. @Roberts R mentioned that he didn't get the console errors - turns out he didn't have "Disable Cache" checked on the Network tab and apparently that made a difference. I always have it checked because Chrome caching drives me crazy but this might be a helpful hint for others.

Just updated the module to version 0.1. Almost everything in it has changed so reading the docs is a must The module does less "magic" as before, eg. doesn't add the "lazyload" class and data-sizes automatically. These should be added manually or you can write a wrapper function if you would like to simplify things (please notify me if you think you wrote one that should be part of the module). Also all the module settings are gone except the "Load scripts" checkbox because all other settings became useless after the rewrite. The new syntax looks like this (here with a helper to add a noscript tag for no-js fallback): <?php $img = $page->featured_image; ?> <img data-srcset="<?php echo $img->srcset('200x300,*2,*3'); ?>" class="lazyload" data-sizes="auto" alt="" /> <noscript> <img src="<?php echo $img->srcsetUrls[0]; ?>" /> </noscript> The main change is that you can easily tell what image sizes (sets) you need ("200x300,*2,*3" in the above example). Of course you can use WxH values for each set or use divisors too. What's more you don't have to start with the lowest image size, eg. "1200x900, /2, /4" is perfectly fine.

Have you checked the console's Network tab - of course make sure this is open before you upload the images, and start by clearing any existing items to make it easier to see - sorry if this is obvious to you already. Do you have PW's debug mode turned on? Also, installing Tracy Debugger might show some otherwise missed errors.

After verifying the login, you can do $users->setCurrentUser($loginUser); Afterwards, $user->isLoggedin() etc. should behave as expected. Setting the user "guest" as the current user (that part hasn't been tested by me) should accomplish the same after a logout.

Laragon allows for multiple virtual hosts so that you need not change your document root. If you do change it to your project's working directory, then it would be served via localhost. As such, the localhost domain should point to the default Laragon www directory, and any virtual hosts you define via the Quick Create method will create a new directory inside the localhost document root, and the virtual host will point to that new directory. So the setup looks something like this: localhost -> path\to\laragon\www (navigating to localhost should show a listing of your vhosts, just to test that it's working) - angie.local -> path\to\laragon\www\angie\ - test.something.local -> path\to\laragon\www\test.something\ - laravel.local -> path\to\laragon\www\laravel\public\ - (etc.) In my case, I have a separate drive just for my sites, and so my document root points to z:\sites. I'd suggest you do is open up the Laragon context menu and select Quick Create -> Configuration. Add the following to the file that opens in Notepad++: ProcessWire=https://github.com/processwire/processwire/archive/master.zip Then, when you go to the Quick Create menu again, you will see ProcessWire listed. Select it, and it will ask you for the name of the project, so just type in the name excluding the domain extension (TLD). It will automatically create the new virtual host that points to the subdirectory in your document root, and your hosts file will be amended automatically. In the case of ProcessWire, the virtual host that Laragon creates will automatically point to the subdirectory as its document root. If you Quick Create Laravel, however, it will point to the sub directory's public directory (as shown above). This is a little 'smart' feature that Laragon has to make peoples lives easier. Hope that clarifies everything for you.

After spending another day on this: It's the theme. The old theme (that comes along in the upgrade) can't display the page list in the backend. But still, seemingly it only works if you do it via the site exporter, and not upgrade the usual way by replacing the wire/index/htaccess..

@billjoseph I may be missing something here but why not simply modify the outer_tpl template in $options to include the Search button? Then it would always be the last item in the menu. 'outer_tpl' => '<ul>||<li><a href="#modal-example" title="Search" uk-toggle>Search</a></li></ul>',

Yep - another Captain Hook update. Often hookable methods for a class are derived from a parent class. Take the "Roles" class for example. It lists add, delete, & save as the hookable methods that are available. But because it extends the "PagesType" class, its hookable methods are also available from the "Roles" class, eg: Roles::deleted. To make these derived methods easier to find, I have added a new: ClassName extends ParentClassName line to each file section. Both names are also linked directly to the API docs so you can find out more info there as well.

Is your image field configured to one image only? if not, try $image->first->url

Thanks @adrian for solving this atm. Issue related to : Installing "SessionHandlerDB" module solves it.

Storing user data in a session is a good way, but if the question in collecting as much user data as possible I would save every answer on each step. In that way, I will have answers from not finished quizzes/surveys.

Yes, you will need to create it. Basically any code in that file will be run when ProcessWire is "ready". You can read more about it here: https://processwire.com/blog/posts/processwire-2.6.7-core-updates-and-more/#new-core-files-for-site-hooks

Sorry for the delay - I got sidetracked. You can fix this easily with a little hook magic. Place this in your /site/ready.php file: $this->addHookAfter("InputfieldRepeater::renderRepeaterLabel", function($event) { $return = $event->return; $event->return = str_replace('#', '', $return); });

Is it always 2 images that work? Do you maybe have Max files set to 2 for the image field? eg:

Thanks, Mike. I've got a handle on it all now. Just me being a dumb@ss

Ah, of course. Url segments is something that can't be supported because of how they're created... No easy way to keep track of them.

This is correct and I do that as well, just only works to add something at the end. I assumed he want to add to a end of a pulldown.

Any reason for using a repeater? (Image fields can hold multiple images anyway, and much easier to manipulate.) See

That's an interesting one. I always tell my clients during training that they need to add an image to the images field first to make it available within the RTE. Your's seem to go down the opposite route by using the RTE insert image icon. The images part of Processwire is probably the only area of the CMS which my clients run into issues and always in two areas. 1. Image tags They often enter the wrong tag or are not sure which tag to assign to an image. This has been improved just recently with the latest image tagging commits. Haven't tried it yet but really looking forward to less UI friction there for my users. 2. Select V Upload Once a user enters the image modal, there's a very prominent 'Upload image" button and a very subtle "select image" instruction. This leads to a lot of confusion and clients uploading the same image twice. Could easily be solved with some simple changes but it's probably low priority. I hadn't come across your particular bug before but it's a nice find.

Hi @Mike Rockett Sorted out the problem and it seems it was to do with my "understanding" of Laragon. I was physically selecting my laragon/www/angie directory as my document root. This allowed me to run angie.local but failed miserably using angie.local/processwire. When I selected c:\laragon\www as my document root, they both work. For some reason, I thought you had to select the directory of the project you were working on but it seems, I missed the point here. Is my "realisation" your understanding too? Cheers

You must have a typo here, so can you please provide your actual version of PHP 5.6? The oldest version of PHP 5.6 should be 5.6.31 http://php.net/downloads.php Thanks

I don't find it long winded but appreciate it could be reviewed. Theres a paid media manager module available which stores all images In a single place.

@psy So, yeah, here's where I throw myself on the mercy of the forums. I will swear to you up and down that I tried that first and it didn't work, but now, of course, it does. Maybe I had the <li> outside the </ul>? Maybe I just like to overthink it? Either way, now I've got two different ways to do it!!

Same provider - two sites - PHP 7.0 - PW 2.6.23 rc2 upgrades works - PW 3.0.42 upgrades gives error. But... there was some old .gitignore file that PW installed in the old days. Removed that and yes! Upgrades are back. I'll keep my fingers crossed and see if they stay...

I can't make sense of that at all -- there's no reason I can think of that it'd be happening. All basic requests to the directory are supposed to be passed through index.php?it={req}, and so if it's not hitting index.php at all (hence the error you're getting), then it can only mean that something is interfering somehow... That's the best guess I have, I'm afraid.

If you have the ability, on a new installation of ProcessWIre with only the ProcessWire Upgrade module installed, what happens? Are all the errors associated with one hosting provider? If so, have you inquired whether they have some security script running that could erroneously flag these websites when the ProcessWire Upgrade module is running? Just looking at all possible explanations. I know it can be very frustrating whenever someone has these types of issues. We will eventually figure out what's happening and correct the issue.

Okay, I've had in the past some installations that were manually done or a combination of manual/different updating methods. Sometimes this gets things out-of-whack where upgrading is concerned. I suggest you: (1) FTP to your actual files and manually delete the ProcessWire Upgrade module. This will alleviate any left-over files that may have accumulated. (2) Click the Refresh button after manually deleting the ProcessWire Upgrade module. This will refresh the cache and alleviate any other problems. (3) Reinstall the ProcessWire Upgrade module using this method. This goes directly to the modules.processwire.com website and pulls an official version of this module. (4) Once you have the ProcessWire Upgrade module reinstalled, check to make sure you are at the latest version (0.0.7 as of this writing). One thing to remember, the ProcessWire Upgrade module requires ProcessWire 2.5.20 or newer to reliably function. (5) Please let us know what version of PHP and ProcessWire you are having this problem with? Are you having this problem with all your ProcessWire sites? If not, what are the differences that you know about? All this will help us to troubleshoot the issues you are having. This does not mean there aren't problems with the module, however we need to eliminate as many factors as possible to get your installations working.

This one comes with quite a pedigree, though - https://design.cms.gov/

Is the frontend still working fine? You could try this:

I have a similar module in use. For security reasons I verify if only one single user has the login email address in use. Emails aren't unique in PW like user names! Furthermore its useful to log login failures. Keep the ProcessWire Login Process safe!

Thanks @flydev and @kongondo Github issue posted: https://github.com/processwire/processwire-issues/issues/360

He's banned off the internet after I found out he was using my credit card to buy bones.

Hi @ryanC, I recently created a profile and added something like this to admin.php: // Add Name Class Module if ( !$modules->isInstalled('BodyClass') ) { $modules->refresh(); } // This is Default require($config->paths->adminTemplates . 'controller.php'); If you sign in to Admin Panel then it should refresh all modules including your automatically ... In addition, you can protect the front file, such as home.php or basic-page.php, as follows: if($modules->BodyClass) { echo 'Your Code'; }

I just tested them, those listed under the "DONT WORK" are not working on ProcessWire 3.0.73. Now why... no idea. Edit: same behavior on ProcessWire 2.8.62

This seems to work just fine with PW 3.x, by the way. Thank you to the author!

After an upgrade from 2.5.2 to 2.6.3 my setup stopped working I cannot choose and insert images anymore in my frontend form CKEditor field with the pwimage plugin. If I click on the insert image button in the editor toolbar, nothing happens and it throws a js error: It seems the way the pwimage plugin works changed significantly. I guess I need to load some additional scripts in the frontend to make this work again but I can't seem to find what is missing. Any help would be much appreciated. EDIT To make frontend forms work, I added this to the head: <?php if ($user->isLoggedin()) { ?> <script> <?php $jsConfig = $config->js(); $jsConfig['urls'] = array( 'root' => $config->urls->root, 'admin' => $config->urls->admin, 'modules' => $config->urls->modules, 'core' => $config->urls->core, 'files' => $config->urls->files, 'templates' => $config->urls->templates, 'adminTemplates' => $config->urls->adminTemplates ); ?> var config = <?php echo json_encode($jsConfig); ?>; </script> <?php } ?> This outputs a JS config variable in json format. When I compare the output of config from the admin page edit source to my frontend page edit source, I find that following part is missing in the config json on the frontend: "modals": { "large": "15,15,30,30,draggable=false,resizable=true,hide=250,show=100", "medium": "50,49,100,100", "small": "100,100,200,200", "full": "0,0,0,0" }, "JqueryWireTabs": { "rememberTabs": 0 }, Now what do I need to add when building the json via PHP so that this gets included also on the frontend? EDIT2: I think I found it. In wire/config.php around line 848 there is $config->modals = array( 'large' => "15,15,30,30,draggable=false,resizable=true,hide=250,show=100", 'medium' => "50,49,100,100", 'small' => "100,100,200,200", 'full' => "0,0,0,0", ); I added this to my code so it now reads: <?php if ($user->isLoggedin()) { ?> <script> <?php $config = $this->wire('config'); $jsConfig = $config->js(); $jsConfig['modals'] = $config->modals; $jsConfig['urls'] = array( 'root' => $config->urls->root, 'admin' => $config->urls->admin, 'modules' => $config->urls->modules, 'core' => $config->urls->core, 'files' => $config->urls->files, 'templates' => $config->urls->templates, 'adminTemplates' => $config->urls->adminTemplates ); ?> var config = <?php echo json_encode($jsConfig); ?>; </script> <?php } ?> And, voila, the modal for selecting images is now working again on my frontend form

Bingo My assumption from my previous post was right. The PWimage plugin needs a hidden text input field with the value set to the page id of the page that you want to grab images from. I added a hidden input field to my form with $imgPageID = $pages->get("template=media, created_users_id=$uID")->id; $field = $modules->get("InputfieldText"); $field->label = " "; $field->attr("id+name","Inputfield_id"); $field->attr("value",$imgPageID); $field->attr("type","hidden"); $adform->append($field); Now I can choose images from the user's images page And there is no custom module with hook to ProcessPageEditImageSelect required. EDIT: This only works for PW 2.5. For 2.6.x some adjustments are needed. You'll find more info here