teppo

Check this thread out: Symptoms are so similar I'd be kind of surprised if it wasn't related

Taking another look at this after a cup of coffee. While I still have no idea what's going on in your site, here's another workaround you could try, though you'll first have to grab the latest version of ProcessVersionControl.module from GitHub. Then add the following to the beginning of the /site/templates/admin.php file: $this->addHookBefore('ProcessVersionControl::executePreview', function(HookEvent $event) { wire('modules')->get('Spex')->setActivePage(null); }); This resets the active page for Spex right before ProcessVersionControl renders it, which in turn should make Spex behave as expected in this situation. If this works, it's probably the cleanest you can get without modifying either Spex or ProcessVersionControl manually (neither of which I'd recommend doing). Hope this helps.

Just wanted to confirm this. I have never gone quite that far myself, but I've found out that Facebook will skip the og:image property completely unless you specify og:image:width and og:image:height with it

Thanks for the update, @SteveB. Like I said, I've never really used Spex, but this change made the bundled example site work as expected. I'm curious about why _init.php wouldn't be loaded at all in your case and why it got loaded in my tests, but then again: it's not a huge surprise that a real-world use case doesn't behave exactly as a minimal example setup If you could provide me with a stripped down setup that doesn't work as expected, I could test this further, but until then I'm probably not going to be of much help here.

@SteveB: I might've figured this out. The problem is related to the way Spex sets up itself. It's a singular module and keeps track of the active page via a property called activePage, the value of which is defined the first time Spex is initiated. In this cases the first loaded page is the admin page for VersionControl. Spex sets that as the active page, and since it isn't meant for admin usage, this prevents some of the necessary methods from being triggered properly. The quick and dirty fix is adding the following to your /site/templates/_init.php file, before any calls to Spex are made: if (!$spex) { $spex = $modules->get('Spex'); $spex->setActivePage($page); } This is based on some quick testing on a module I'm not familiar with, so please take your time testing this properly, but so far it does seem to work for me. Another approach would be detecting Spex in the ProcessVersionControl::executePreview method, but to be honest I don't like the idea of adding module-specific workarounds there. From my point of view this is not a problem of VersionControl, but rather related to the way Spex works.

Sorry, I've never actually used Spex myself, but just a quick comment: that URL triggers the executePreview() method of ProcessVersionControl.module, which in turn tries to render the given page in a specific version. It sounds like rendering the page this way is a problem, though I have no idea why. Someone with proper understanding of Spex could probably answer that one

The French example seems to make sense, but as far as I can tell, English versions make more sense when the apostrophe is removed: lets-go vs. let-s-go, havent-been-there vs. haven-t-been-there, adrians-suggestion vs. adrian-s-suggestion, etc. I'd suggest going with Adrian's suggestion above.

The issue mentioned above was related to a recent change in the core class InputfieldWrapper. I've just created an issue for this to the ProcessWire repository in GitHub (https://github.com/ryancramerdesign/ProcessWire/issues/1936) and updated VersionControl to circumvent this issue. If you update the module to the latest version, it should work again. Sorry for the inconvenience! /cc @diogo, @ceberlin, @Zeka

@Can: Sorry for the delay. So far I haven't been able to reproduce the issue you're seeing, which is making it quite difficult to debug. This is one of those cases where it would be tremendously useful to be able to check which values LinkCrawler gets from the Process module, what $this->config contains, what that "unrecognized" render method really is, and so on Not calling the module from a template file isn't a problem, but I'm a bit confused why it would throw the "unrecognized render method" error. Could you check what the module config page of ProcessLinkChecker lists as the render method? This error should only happen if render_method config setting contains something weird or if it's undefined. At this point I can only assume that either LinkCrawler doesn't have access to the ProcessLinkChecker module (it tries to get it's config from there) or those config variables are somehow mishandled. Just checking, but is the above snippet the only code in that file? I assume it's bootstrapping the same ProcessWire installation that has ProcessLinkChecker installed, right?

"This CMS will sometimes include a meta tag within the html of each page". Kind of misinformation considering that ProcessWire will not include anything in your markup by itself, but I guess that's just some boilerplate content so no biggie. Also: congratulations to innobloom for getting listed there!

What you've got there is an instance of Pageimages, i.e. multiple Pageimage objects. Note that when bootstrapping ProcessWire you've got output formatting off, which means that this is what you typically get when requesting the value of an image field. If you just want to grab the first image and resize it, use first(): echo $page->images->first()->size(100,100); If you're unsure about how many images there will be, you'll need to iterate over them with foreach or something similar. Like @horst pointed out, if you provide us with a bit more context, it'll be easier to help you out.

Thanks, @Zeka – that's a nice roundup right there! The thing I disagree with is your point about this not adding to the cognitive load. In my opinion you can't add anything new without increasing the cognitive load (unless, of course, it's a change that reduces or greatly clarifies something that's already there). It's also worth pointing out that most new features make the underlying logic more complex. While we're talking about relatively small amounts here, adding "just something small" repeatedly is a well-known way to ruin a perfectly good GUI. In my opinion each and every feature should a) be useful to a majority (or at least a relatively large percentage) of users out there, and b) be as obvious as possible. As long as both of those are true here, I'm for this feature. Otherwise I'd suggest looking into some way to implement it as a module or some other way that makes it 100% optional.

Sounds great, but one technical note: instead of exit or die, most of the time you should be using $this->halt(). This way ProcessWire can still shutdown as expected.

Different background on hover makes sense to me, even if it won't play nicely together with touch events. I would keep the checkerboard pattern mainly because otherwise there's slightly bigger chance of the image disappearing into the background completely.

@Can: The issue you mentioned should be fixed in the latest version of LinkCrawler.php, though please let me know if it still persists. The problem was that LinkCrawler didn't have access to $wire from the global scope, but since PROCESSWIRE was already defined, it wasn't attempting to instantiate ProcessWire either. I'm no longer entirely sure that current behaviour makes sense in this case (perhaps I should rather allow the user to pass an instance of ProcessWire to LinkCrawler when instantiating it) but at least this seems to fix the issue at hand

Weirdest thing: was about to post literally the same percentage as Antti this morning, based on my own experience. I've stumbled upon similar need *once* among all the sites I've worked with so far. If I'm anywhere close to a "typical user", having a visible toggle for this would be just redundant cognitive load to majority of users out there (not to mention unnecessary technical debt for the system) and thus I would vote against it. Always ready to rethink my opinion if others have very different experiences. Who knows, I might be in the minority here

@Can: Thanks, I'll take a closer look at this ASAP.

Perhaps not particularly helpful (sorry), but to be honest this sounds like something you should always do via an API. If the company hosting those properties intends them to be available to others this way, usually they would provide an API to said content. If they don't, it's possible that they wouldn't like anyone crawling their content either With some quick googling I found some hints that the company behind the actual platform (Immformer) might offer additional features etc. so I wouldn't be too surprised if they offered, either as a part of the platform or as a plugin/addition, some way to export entries. I don't know anything about your client's relation to the site in question and the relation of that site to the platform they're using so it's very difficult to say who you would contact in this case, but anyway: in my opinion the only future-proof, stable solution you're going to find would need co-operation from the management of the NetMakler site and perhaps the provider of the platform they're using. Anything else is, at the very least, very likely to break every time something changes at the site

@SteveB: shouldn't require any tricks, but to be honest I've never used such a setup myself, so it's probably a mistake on my side. I'll take a closer look at that ASAP @Juergen: README includes instructions for setting up a cron job. The gist of it is that you should make a cron job that runs the module's own Init.php file periodically. To be honest I'm not entirely sure what you mean by a cron job module or ready.php in this context – but please let me know what I'm missing!

Regarding 404, there has been some earlier discussion in this issue: https://github.com/ryancramerdesign/ProcessWire/issues/809. In my opinion this is not a very good design decision, but currently this is not easy to circumvent. Trash is another issue, and for that you should check out Trashman. Allowing access to trash is another design decision I find less than optimal, but luckily Trashman provides a viable alternative for that.

To be completely fair, it is a part of the core and it doesn't require a module The easiest way to handle this is to create a page to contain images (or multiple pages, separated into categories, or whatever) and then, when embedding an image, choose to use an image from one of these pages instead of the current one. That's just about it. The modules that handle something like this are largely just layers of abstraction built to hide the underlying concept from the end user. Sure, if your needs are massive then you might require a more complex solution to solve them, but something as simple as reusable images are very easy to set up using nothing but the tools that ProcessWire already ships with

Absolutely true. Rest of this sentence was great too, but just wanted to point out that I fully agree with this: if someone prefers platform Y over PW in a specific case, that's their call to make. They may or may not have good reasoning behind that decision, but that doesn't change the fact that it's still theirs to make. Someone I used to work with once explained to me that "WP is awesome because I don't have to know anything about web development to add new features to my site". For most users, even those who describe themselves as "developers", that's really the gist of it: being able to add features in a cost-effective way and without having to understand what's really going on behind the scenes. While this approach no doubt has it's benefits, sometimes the result is this: "Grade D, 10.29 seconds load time, 3.5 MB page size, and 206 (!!) requests." Or worse, a hacked site because one or more of those plugins you installed were badly written and you didn't have the time, money or knowledge needed to spot those issues, or perhaps you neglected to monitor the site and install all those updates in time. I'm not saying that WP can't be used to develop sites "the proper way", or that you actually have to keep installing stuff until your site breaks, but it's good to realise that what is often considered the biggest benefit of the system (ability to add features with no so-called programming knowledge) is also one of the easiest ways to completely wreck it. Each and every feature you add to the site increases the amount of technical debt, that's just how it works.

Looks like I've missed some messages here. I'm currently using this on a couple of sites with no issues; ProcessWire 2.7.2 and 3.0.18, on two separate servers. Would be interesting to hear if aforementioned issues still exist.

This could mean that *all* users on the system have read and execute permissions on your webroot, which would be very bad indeed. Though this doesn't allow everyone to write new files in your webroot itself, as long as you have a writable directory inside executable one, those users *will* be able to write and execute files there. This, in turn, would give them just about everything they need to compromise your site. Of course this still depends on them having similar access to the directory your webroot is in, and the host not having implemented proper chroot / jail method. I can recall some vulnerabilities that have allowed users to break out of a chroot jail, so it's not exactly 100% reliable method either, but as long as the server is kept up to date it should prevent most issues like these.

There are two potential issues here: your form doesn't seem to have CSRF protection in place and the lack of HTTPS connection would make it possible for someone to grab the credentials from a request, but other than that this looks fine to me. My usual advice would be not to do this (use built-in login form instead), but of course there are cases where you don't want to do that. For those cases check this post out for the CSRF protection and enable HTTPS. If the price of the SSL certificate is an issue, check out Let's Encrypt; their free certificates are pretty awesome. If your host doesn't allow you to use these, that in itself could be a good reason to switch hosts.