teppo

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.

Note: this topic has been moved to the Module/Plugin Development subforum.

It's a real shame that your site got hacked, but this is definitely something we can learn from, so thanks for sharing it. Shared hosting and lax file permissions are an easy way to get into trouble, but I'm still quite curious about how exactly the site was hacked. From what you've mentioned here (uploaded files, etc.) it kind of sounds like the login credentials might've been compromised, or did you perhaps have something on the front-end that could've caused that? Of course if it really was an "inside job", i.e. if the site was attacked by another user on the same shared server, the files inside /site/assets/ could've been planted there manually. Did you have anything else installed on the same hosting account, another site or web application or anything? If you do find out anything else, please let us know, but just in case: if it turns out that this was actually a result of a flaw in the system itself or perhaps a third party module, please let Ryan know of it before posting to the public forums. I'm extremely confident in the security of the core and have a lot of trust in most of our third party modules, but there's no guarantee that nothing will ever go wrong.

@SteveB: thanks for sharing this. Generally speaking I'd advice against a setup where the site can be accessed with both www and non-www domain – for reasons that include SEO considerations, caching, and consistency in general – but there are many situations where multiple httpHosts can (and should) be present and this kind of situation might occur, in which case it's good to keep this feature in mind

Hello there and welcome to the forum! We do have site profiles for ProcessWire, so you might want to check those out. Generally speaking they're intended as a "starting point", and you will no doubt have to dig into both front-end and back-end work, at least to some extent. You might also want to check out our markup modules, which may provide some helpful shortcuts for your site building. Since jQuery is just a front-end JavaScript library, you can easily include it on your site, just like any other 3rd party JavaScript library out there. Same thing goes for front-end frameworks like Bootstrap or Foundation: ProcessWire itself doesn't generate any markup for you, which means that you can use any given framework to build your site. ProcessWire is very different from WordPress, and developing sites with ProcessWire is similarly different. I would suggest giving it a try, but if you're looking for a solution that lets you simply start with a complete theme, install all required features as modules, and never touch code or markup.. well, in that case ProcessWire probably isn't the best option for you. On the other hand if you're interested in learning how to build actually working sites and you're not afraid to get your hands dirty every now and then, you'll no doubt fall in love with ProcessWire and the awesome developer API it provides Hope this helps a bit.

Was literally thinking about the same thing just yesterday. Solved it by a combination of JavaScript targeting only links to assets and instructing users to apply target "_self" to file links they don't want to open in a new window/tab. That's definitely less intuitive than having target "_blank" automatically selected, but does the trick Another option would be injecting JavaScript for when Page Edit Link is rendered and handling this there. In that case it would probably make sense to track the change event of the file input and act on that, perhaps combined with a check that avoids changing the target value if the user has already changed it manually. Just for the record, it would be nice to see a built-in setting for this. I'd assume this to be a relatively common need.