Leaderboard

That's quite strange. Running this through decoder suggests that this include is trying to load file from /wire/modules/System/.db9f7664.ico. Is this a path that exists on your site, and if so, what's in that file? /wire/modules/System/ is a path where SystemUpdater and SystemNotifications live, but I'm not aware of anything that should create a file like that. Combined with files suddenly being removed and this file getting modified, it doesn't sound good. The first thing to do would be to check the server, i.e. is it possible that someone has gained illegitimate access to it. Is this a shared host, a VPS, or something else entirely? Were both sites on the same host? I'm not aware of any security issues with ProcessWire itself, but ProcessWire isn't immune to problems caused by someone gaining access to the server, directly or through another application (such as a WordPress installation – which has actually happened before).

From what I can tell, some might have gained access to your server/account . I have seen this before with wordpress sites. Has anything with your server changed lately? Also, I would check with your host to check if this is not just effecting you. Just in the short term, I would change your ftp credentials.

There are a few things that came up in my mind right now. First I thought it looked like a failed git/SVN merge of some kind but afterwards it looked liked a failed upload from FileZilla. At least they both look pretty similar somehow. As you stated that there are more instances of other sites and CMSs on that hosting you might want to try to set up different users for different sites. I guess you are using a US hosting company such as DreamH*st, H*stgator or Blueh*st, *2, or another 3.99/month mass-hosting ... I had several similar issues with these companies in the past - but to their rescue - they offer different users on a account to separate installations/instances of different sites. TL;DR: what @teppo and @louisstephens say seems to be the case... someone got somehow access to that hosting. Maybe even through a nifty trick in W*rdPress.

Just my opinion: I'm not sure there's much advantage to doing that - selector arrays seem more trouble than they are worth. When you start needing things like OR groups and nested selectors (which you inevitably do) the array syntax gets quite verbose and frankly less readable than the string syntax (especially if you are already familiar with the string syntax). I can't locate the topic now but I remember @adrian working with selector arrays for a while and I think he ended up reverting back to selector strings because there were too many issues/hassles with the array syntax. Maybe he will correct me on that.

Thanks for your help @Zeka! Did find this topic while searching for a hint. I am familiar with OR groups, but what I am trying to do here is "migrate" from using string selectors to array selectors, but I can't just get them to behave like its string equivalent! I understand it will be hard to debug this without the whole scope of the ProcessWire project but maybe some has been through the some of the same issues.

Thanks @MarcoPLY. Yes, I was already aware of it but it is great of you to bring it up like this for the benefit of everyone else.

I will look into updating the Payment modules to use latest Stripe libraries. Other than that this change shouldn't require any changes for webshops and websites using payment modules, since that authentication is done between stripe and payment processors (banks, cc companies etc).

From time to time, I copy/paste snippets of code in the forum here to my editor (SublimeText). Unfortunately, I think the forum software sometimes throws in invalid, INVISIBLE unicode characters that break the copied code and usually will throw PHP errors that at first sight don't make any sense. These characters are impossible to detect in SublimeText, but with the following plugin I just discovered, it will identify them: https://packagecontrol.io/packages/Gremlins

Ah, the early days of discovering ProcessWire and enjoying the constant feedback loops of development bliss. This is a great site. I love seeing PW + ecommerce.

At least to some degree related, no doubt! The reason I'm asking about ways to bundle dependencies into site profiles is that I was originally a bit conflicted about how to move forward with a project I'm currently working on. Based on the description in that thread there are definitely certain similarities with my project and what Jonathan is working on, but I'm not yet quite sure if there's any real common ground (except, perhaps, the target group) ? Either way it'd definitely be interesting to hear more about Jonathan's project – and perhaps share/borrow some ideas as well ?

A few days ago I received an e-mail from Stripe where he said that by the 14th of September, two-factor authentication should be implemented for online payments. --> article I seem to understand that for the module ecommere here on PW we need to update the API. They sent me to this page: here Or other possibility is to use the new version of Stripe's checkout, at this link. I wanted to ask if someone has plans to update the module? ------ @kongondo, probably you already know, but anyway for the new version of Padloper this could be interesting.

I just made the switch from Sublime Text 3. Been using it for years and really liking Visual Studio Code. Here is what I have installed so far: Auto Rename Tag Bracket Pair Colorizer Color Highlight Insert Date String Live Server Markdown Preview Enhanced Numbers Bookmarks Polacode Prettier Code Formatter Project Manager Settings Sync Sublime Text Keymaps and Settings Importer Todo Tree vscode-icons WakaTime

Hi, based on the work of @microcipcip and @gebeer (see their posts here and here), I put together a Processwire + React boilerplate (profile). Github repo: https://github.com/lapico/process-react Cheers, K

Actually all of the above, but yes, the Tracy dump is a key part of it - so much easier to see which parts are being added to the selector this way. I do also sometimes modify parts by key, but I also just find my code looks cleaner that concatenating a string with commas at the end of each one, plus you don't have to worry about a possible trailing comma.

PS, here's the thread @Robin S was referring to:

Yeah, @Robin S is mostly correct. The array approach seems like a good idea, but it will end up biting you in many cases. For ease of readability and building up complex selectors, I do build them with a regular php array and then simply implode the array with a comma to get the string selector. This is now my goto approach for any complex dynamic selectors.

Most certainly a good moment to create a more secure environment. Thanks

That's far from the best and ideal solution to go on vacation but did you change something within the path that @teppo mentioned? Even if so... the index.php is still somewhere else than that path. It's either weird or a good moment to change and set up a better and more secure environment.

I think I did, but I can't remember. I think these links helped me. Hope that helps you

Thanks Louis Teppo Ive just gone through and done this. WordPress still haunting me ha

Thanks for your feedback. Job pages are created using a front end form. In order to trash the old jobs, I ended up with the following code: $jobs = wire('pages')->find("template=job-template, parent=/expired-jobs/, include=unpublished"); foreach($jobs as $job) { $job->trash(); } Now, regarding the problem of adding a unique value to each job link, I guess I would have to update Processwire first in order to access the PageNames and WireRandom classes?

I'm seeing the images now on my computer.

Upgrade Path: Padloper 1 to Padloper 2 I have been getting a number of enquiries regarding upgrading from Padloper 1 to 2. I would to reiterate that whilst there isn't a direct upgrade path, it is still possible to import products from Padloper 1 (or any other shop system for that matter) to Padloper 2 using either the API ($padloper->importProducts($imports);// array/json/csv) or the GUI. However, please note the following: You will have to export products from Padloper 1 yourself. No script will be provided for that. You will have to do any manual cleanup of the data as well as additions to the data yourself. Documentation will be provided about the fields required for the import into Padloper 2, e.g. Product title, description, etc, and any optional fields. Supported import formats are JSON, CSV or arrays. Importing into Padloper 2 does not have to be a one-off exercise. Import will have the option to overwrite/update/skip existing identical products. I hope this clarifies things.

I just published another update that makes full use of the Add to Home Screen functionality in Chrome (though the app is installable in Android Chrome, Android Firefox, iOS Safari and regular Chrome). In particular, there's a new page that explains how to install the PWA on different devices, with a button that triggers the system dialogue for installing the PWA on supported browsers (only Chrome at the moment). This was a bit difficult to implement since there's little common ground between browsers in this regard at the moment, so let me know if you find any bugs or other errors! @charger ProcessWire only handles specific paths, everything else is routed to the frontend app and handled by the router. A normal ProcessWire installation uses the .htaccess rules to redirect all requests to it's index.php file. Meanwhile, the Vue SPA uses one single index.html as it's entry point and performs all further routing inside the visitor's browser. Since I want most visitors and paths to go to the frontend app, I modified the .htaccess file ProcessWire comes with to only forward specific routes to ProcessWire, and route all other requests to the Vue app: # .htaccess # Requests to the root domain without a path should go to the Vue app (index.html) instead of ProcessWire (index.php) DirectoryIndex index.html index.php index.htm # This additional RewriteCond comes right before the main RewriteRule from ProcessWire # It lets ProcessWire handle only calls to specific paths (in this case, the admin url (/cms), the API endpoint and the sitemap which is generated server-side) RewriteCond %{REQUEST_URI} (^|/)(api|cms|sitemap) RewriteRule ^(.*)$ index.php?it=$1 [L,QSA] # Everything else is routed to index.html, so the Vue app will receive the request and the vue-router can show the appropriate page # Redirect index.html to / RewriteRule ^index\.html$ / [L,R=301] # Redirect everything else to the app FallbackResource /index.html

Here is a screenshot of the images not loading from my iPad. I also checked on a computer, both chrome and safari.

https://github.com/processwire/processwire/pulls There are still pull requests from 2016... Please @ryan could you take a look at the PR repository just like you did with the issues over the last weeks? There are many simple ones that really just need to be merged (like https://github.com/processwire/processwire/pull/143/commits/80aa0ac2e6383b32a4d0a932d5bec78a8fb5bf14 ). It's really frustrating if one tries to contribute and this contributions just seem to be ignored ?

Hi, Field tags, the ones used for grouping up fields in the backend, used to have this feature where you add a "-" in front of one of them and it collapses the group. Now after updating PW the new tag editor is nice, but it's impossible to delete the old -tags. How does one clean those up? Renaming one doesn't do anything. Neither does removing the fields inside one. It seems the "-" in front of the name is preventing PW from changing them. Do I need to delete them manually from the database? And if so where from? EDIT: Figured it out myself. You have to go through each individual field and remove or change the tag name from there, instead of using the tag interface.

FYI , there is a really good language-pack for French : https://github.com/v-maillard/pw-lang-fr All work already done ?

I'll first need to release SnipWire and in the phase of fine-tuning I would like to move some of the functionality into separate modules. A chart module could be such a candidate. I'm gonna check out your module and see how you were thinking of implementing that. Thanks for your hint! The first separate module will be a fully configurable array/json repeater Inputfield which stores its values in a single text field.

Thanks for the detailed write-up! Would you mind sharing how exactly you sync the PW routes with Vue router?

VSCode plugin: https://marketplace.visualstudio.com/items?itemName=nhoizey.gremlins

Yay! ?

Very nice site! One thing I noticed was that the images were broken on https://www.us.playwood.it/en/free-design-projects/

Sounds like this issue is sowewhat related to this one: https://processwire.com/talk/topic/21716-processwire-profiles-whats-missing/?do=findComment&comment=186721 Maybe @Jonathan Lahijani has already come up with his "solution"? Quote: "...I don't know what term would accurately describe it, but its a ProcessWire module that's an opinionated, update-able starting point, oriented towards developers..."

If it's worth making the update, there is a new class PageNames with methods for this purpose. https://processwire.com/blog/posts/pw-3.0.111/

You could do the following in your template to delete pages: $jobs = $pages->find("template=your-template, parent.name=expired-jobs"); foreach($jobs as $job) { //$job->trash(); this will trash the page $job->delete(); } How are you currently creating the jobs? Are you creating them from a front end form and using the api to create the new page?

Thanks Benjamin! What you're saying makes sense, and I've also come to terms with the fact that the contents of the site profile itself (mainly what's within the templates directory) won't be easily updated. They are, after all, intended to be modified, and as such "updating" them doesn't make a whole lot of sense. I do also agree that we're in a bit of a strange place right now: on one hand there are native (to ProcessWire) ways to handle things like dependencies, but on the other hand we've also got certain level of built-in support for Composer. That's not necessarily a bad thing, though: just for an example, folks have been doing stuff like installing modules from within the Admin for quite some time now, while I still haven't enabled that on any of the sites I've built – and won't, unless it's for a site that someone else is going to manage. First of all I prefer not to give the site easy write access to executable code (security), and second of all I've had some trouble making that work with my version control and deployment practices. (There are other reasons too, but those have always been my "top two".) The way I see it, the tools and practices I prefer are quite likely not what the "mainstream user" prefers – and I'm OK with that. Same goes for the dependency management: in my case I'm thinking that whatever solution is used should be reliable, easy (comparatively: running a few commands from command-line is easy), automatable, and compatible with different workflows (including things like CI/CD tools). The fact that ProcessWire caters for these tools just as it does for the built-in alternatives is a strength in my books. Anyway, I guess this once again boils down to the rather well established point that there's more than one way to do it ? -- Sidenote: to my best knowledge GitHub download feature actually doesn't include submodules, so the only way to have everything as an easily downloaded package is to bundle it all together. This is part of the reason why I don't (currently) think that submodules are worth the hassle.

You can assign the fields again and save again just like you are doing right now, there's also just field saving like this: $page->some_field = "new value"; $page->save('some_field'); In this scenario I think either is just fine, just useful to know when you get into hooks and stuff like that ?

So would caching be an (easy) option? At the moment this is how RockGrid works: It makes one query to get one row (so the query should have limit=0,1) so that it knows which columns to setup for the grid. Then the second request is to get all data (and this is also used for all subsequent requests when reloading the grid). This is not the best solution, but I have no plans to change that for RockGrid. I start working on RockTabulator today where it will load all the data at the first request and display it instantly ?

I've just notified Ryan about the removal, thanks for letting us know!

Hey @ryan, Just wondering if you saw my update to the WebP functionality? https://github.com/processwire/processwire/pull/145

Important security update! Hi RockGrid users, I'm very sorry for that, but I have to announce a security update. If you are using RockGrid on a public site please upgrade to v0.0.22 (Fieldtype) immediately. It is a simple but important update: https://github.com/BernhardBaumrock/FieldtypeRockGrid/commit/0be2086139c84f775937246ed2985ac4c4a3e9c3; The proplem exists on all RockGrid fields with AJAX turned ON. In this case it was theoretically possible to expose the field data to a user that should not be allowed to see this data (in the worst case even a guest user) if the user knew how to do it and he also knew the name of the rockgrid field. The update now restricts access for AJAX field data to superusers only. You can easily adjust that via simple hooks: // rockgrid access control $wire->addHookAfter("InputfieldRockGrid::access", function(HookEvent $event) { // all grid data is accessible for all logged in users $event->return = $this->user->isLoggedin(); }); Or more granular via the fieldname: // rockgrid access control $wire->addHookAfter("InputfieldRockGrid::access", function(HookEvent $event) { $field = $event->arguments(0); $user = $this->user; $access = $event->return; switch($field) { case 'field1': case 'field2': case 'field3': $access = $user->isLoggedin(); break; case 'field4': $access = ($user->name == 'foo'); break; } $event->return = $access; }); Field 1-3 is allowed for logged in users, field4 only for user foo and all other fields only for superusers (default rule). I'm not totally happy any more with several aspects of RockFinder and RockGrid, but it is the best option I have so far (until I can build something totally new, maybe with tabulator if tests work well). Special thx to @Zeka for bringing this issue to my attention by coincidence in the other topic!

I dont think I have it down yet. I really think a page builder needs to live update while you change fields to be competitive with things like DIVI and Beaverbuilder and Elementor. This is what I am working on with vue. I am just looping through all fields attached to the page and making vue form fields that have 2 way databinding. So when you type new text in, it changes as you type. Or if you hit center text, it centers it instantly. I am using the REST API plugin to push the page data back to the database when you hit save. I plan on releasing the site profile to the community when I am done. It should be better than the above wordpress solutions as they are very hack solutions. You can not, for example, add any element inside a tab module or an accordian. You can only type manual code into their rich text. With mine, I can add a grid with columns or really anything inside anything.

We recently finished the relaunch auf camac.de, a client from the software industry, focused on controlling and business integration solutions. Concept, design and implementation by schwarzdesign. The site is focussed on longer content pages with text and image combination, with technical information for potential customers. It also offers multiple options for Call-to-Action elements to maximize conversions. Finally, the site is heavily optimized with caching and minification at every stop to be instantly readable even on slow connections. Features No hard-coded sections in any template: Almost all content types use the same repeater matrix field with several section types. This way, the entire site and all parts of the layout can be moved around and combined in any way imaginable. Custom Call-to-Action options: Two different contact forms, custom external links or a general CTA text. Automatically generated page navigation and human-readable anchors (as seen here) Every page fully loaded and interactive in ~1 second, even on poor mobile connections Automatically generated SEO meta tags, with overwrite fields available on every page Modules used ProFields FormBuilder Tracy Debugger Sitemap Duplicator ALIF - Admin Links In Frontend WireMailSMTP Content and conversions Every visitor is a potential customer - this is why we made sure there are ample opportunities to generate leads. At the end of every page, there are multiple options for the CTA section: A contact form with a customizable message (built with FormBuilder) A download form that allows visitors to download PDFs (e.g. the full article) in exchange for their name and E-Mail address. Other text + image combinations with custom links or buttons. The download form was custom coded, as it allows the editor to upload a file specific to the current page and make it available behind a small form. After successfully submitting the form, an e-mail is sent to the site owner, and the file is directly streamed to the client as a download. Technical insights This is one of the first pages where I used Twig for templating, and it's been a great developing experience. With Twig, you get content escaping and much better seperation between logic and view / display. I also spent some time working out a solid structure for the twig templates, with useful defaults, reusable blocks for page and section template (you can read more about the approach in my recent tutorial on integrating Twig with ProcessWire, part 1 and part 2). I also started using Parcel as a lightweight alternative for Webpack, when all I need is to compile a couple of small scripts (for the navigation, the lightbox, a dismissable cookie notice et c). What's great about parcel is that you get bundling of your own code and external libraries out of the box, as well as ES6+ transpilation and minification for production usage. Still, it required no configuration but a couple of command line options. This way, you get one bundled, minified JavaScript file, the same way we produce a minified CSS file with SCSS, but without the additional overhead of configuring Webpack. Screenshots

No; Intelephense, not IntelliSense :-).

My strategy is to get rid of those characters right off the bat, instead of detecting them. Here is a previous post of mine: https://processwire.com/talk/topic/20865-permissions-for-page-reference-field-linked-to-users/?do=findComment&comment=180797 By having a system wide tool, one can even use it anywhere not just in a favorite editor. I also use little tools like turning strings into "url friendly string", "lowercase/UPPERCASE/CamelCase". BTW, the new forum update is very aggressively turns forum ULRs into those big preview boxes. Previous version transformed the link right after pasting it in but not later on. This new forum versions keeps converting the links – on seemingly random occasions – even after I have opted for the "plain text" version . Very annoying.

I recommend using tools like: https://www.bluem.net/en/projects/plain-clip/ (macOS, I do use it) https://stevemiller.net/puretext/ (Windows, I've just goggled it ? ) more on this: https://www.makeuseof.com/tag/5-ways-strip-formatting-copy-paste-text/ (I've just goggled it ? ) For Plain Clip.app and similar one can setup a global shortcut launching some simple custom made script – I use the commercial Keyboard Maestro but there should be free alternatives out there – so that one can easily paste clean text no matter what the source is.

or maybe we should leave the modules directory as is, and then make the Process module install the other module? I guess that would solve this – so i just need to move the "installs" configuration setting from the non-process to the process...

Getting just the folder means $file is actually not a file (Pagefile), but a Pagefiles object. File fields are internally always handled as list of files, so you might need to use the following or alike: $file = $upload->file->first();

Yeah, I think you are right. I'm going to change this.