Leaderboard

Hi, I added the 7G firewall htaccess rules to a site, and was getting errors in the PW admin as JS files were failing to load. The culprit is line 85 (v1.2): RewriteCond %{REQUEST_URI} (/)((php|web)?shell|conf(ig)?|crossdomain|fileditor|locus7|nstview|php(get|remoteview|writer)|r57|remview|sshphp|storm7|webadmin)(.*)(\.|\() [NC,OR] It is the conf(ig) part that prevents some PW admin JS files from being loaded (e.g. /wire/modules/AdminTheme/AdminThemeUikit/config-field.js). I removed this so the line becomes: RewriteCond %{REQUEST_URI} (/)((php|web)?shell|crossdomain|fileditor|locus7|nstview|php(get|remoteview|writer)|r57|remview|sshphp|storm7|webadmin)(.*)(\.|\() [NC,OR] Hopefully this will same some future users of the 7G firewall some time! If you come across any other issues using 7G with PW, please post them here! Cheers, Chris

Set the form action to the be the same URL that renders the form. Or just don't set the action for the form because the current URL is the default action. Look for the name of the submit button ("submit" is the default) in $input->post and process the form input when it is present. Example: public function ___execute() { $input = $this->wire('input'); $modules = $this->wire('modules'); /** @var InputfieldForm $form */ $form = $modules->get('InputfieldForm'); /** @var InputfieldText $f */ $f = $modules->get('InputfieldText'); $f->name = 'greeting'; $f->label = 'Greeting'; $form->add($f); /** @var InputfieldText $f */ $f = $modules->get('InputfieldText'); $f->name = 'name'; $f->label = 'Name'; $f->required = true; $form->add($f); /** @var InputfieldSubmit $f */ $s = $modules->get('InputfieldSubmit'); $form->add($s); // Process input if form was submitted if($input->post('submit')) { // Core form processing (required, etc) $form->processInput($input->post); // Custom processing $greeting = $form->getChildByName('greeting'); if($greeting->value !== 'Hello') { $greeting->error('Please say "Hello"'); } // Redirect (Post/Redirect/Get pattern) $this->wire('session')->redirect('./'); } return $form->render(); }

Although doable, I'd only recommend a system like this to be implemented using ProcessWire if the rest of the project must (or already is) be highly coupled with PW and it doesn't make sense to decouple it for whatever reason. Otherwise I'd recommend you to implement it using another framework. PW shines in the content management part, and I love it, but it may present you with some limitations in its developer-experience department when you need to implement some business logic that relies heavily on integration of payment systems, user data input, generation of reports and especially tests. There's also a myriad of similar systems like this already implemented that you can use as a base, like this one https://github.com/LaravelDaily/Laravel-Test-Result-PDF (demo: https://www.youtube.com/watch?v=GmLFHGud7I8).

Collecting super long referrer values seems pointless (they're likely spam anyway), so truncating seems like a good approach. And the same applies to UA string as well ? -- Edit: just checked a few log files, and I've got similar errors there... and some of these: Exception: SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'user_agent' at row 1 (in /site/modules/ProcessJumplinks/ProcessJumplinks.module.php line 534)

I tried both but it didn't help. Also I uninstalled and removed the module, deleted all cookies, local storage and session storage and then reinstalled. Problem persists. Can't see what the invalid escape sequence could possibly be. On my local dev install of the website, I don't have that problem. I'll try to find the cause for this behaviour and will let you know here. Thanks again.

I'm going to start from the end, because this is the easy part (maybe) ? First of all, all the main concepts found from Wireframe have been around, in one form or another, for about a decade. Wireframe (the module) was developed a couple of years ago, and components were added about six months ago. Partials have been around since the very beginning, while components are a brand new thing. As for "should there be both partials and components", this is a good question going forward: Components are more versatile, but also more complex. There's a class (for business logic) and one or more views (for markup). Partials are a lot simpler. Even though you can pass params to partials and arrange them in directories by type or whatever, they are essentially just individual include files. In my typical project there's a need for both: by default I prefer the simplicity of partials, but if I really need to do something more complex on a per-element basis (justifying the mental and technical overhead of the class based approach), I go with a component instead. Heck, in one recent project I even surprised myself by using components within components. Not what I'd call an "easy to grasp setup" (which is always something that I try to emphasize in my work), but it gets the job done and was fun to work on. Will components and partials eventually merge into one? I don't know — maybe, maybe not. For the time being I quite like having them both around. In my projects they tend to solve different problems, even though they could be used interchangeably ? Oh, I'm sure that this makes a huge difference! As I've mentioned before I haven't really used custom Page classes, because — for my use cases — controllers provide same benefits, and then some more. Nevertheless, had custom page classes existed when I started working on Wireframe, there's a good chance that I would've taken an entirely different route ? I might've already touched some of the same topics earlier — particularly the one about having more than one type of object in Wireframe — but a few additional notes on this: You don't have to use anything you don't need. Layouts, views, and controllers are all optional. In many of my projects there's one layout, a bunch of views (often much fewer than there are viewable templates, since many templates are so simple that the layout file takes care of all the markup), and a few controllers (just for those templates that require something "more complex" behind the scenes; news or event containers / lists, page search, etc. The "everything is a component" approach is quite possible with Wireframe, though that was never really something I intended (or expected, to be honest!) The roots of Wireframe are in the MVC architecture, and that's where controllers, view, and model (which in this case is actually ProcessWire) come in. Components were intended as something that you can use to "fill in the gaps"; a bit like utility classes, for that matter. When you say that "Controllers are tied to the template of the viewed page", that's actually not entirely true: by default Wireframe will indeed only know that for a Page using the "basic-page" template it should check if a controller class called BasicPageController exists... but you can also make multiple pages share a single controller, change the controller on the fly, etc. Much of this is pretty new and I'm still experimenting with it, but I have high hopes that it will become even more useful in the future. As for the "couldn't that also be handled by the component" part: controllers do certain things that components don't, there's always exactly one controller active for a specific page at any given time, and these two work in a different context. The context of a controller is a page render request, while the context of a component is much smaller — essentially the subset of the request that it has been provided with. In my opinion it's best to keep them as separate concepts — at least for the time being — though once again who knows what will happen in the future ?‍♂️ I hope I don't really need to say this, but... feedback, comments, and (constructive) criticism is always welcome. I can't promise that I'll agree with all of it, but I'm happy to hear others' experiences nevertheless ?? -- I'm pretty sure that you've seen this already, but I've got a couple of site profiles online — https://github.com/wireframe-framework/site-wireframe-docs and https://github.com/wireframe-framework/site-wireframe-boilerplate. These are a bit dated by now (neither uses components, for an example), but they may provide some insight into the way I personally use Wireframe. I've been really looking forward to revisiting the weekly.pw website and sharing that as well, hopefully something I can get done before the end of the year. This site is also really, really dated (both visually and feature wise), and I'd also like to show off some of the new stuff in Wireframe ?

As i mentioned before; I started my own e-commerce project and had to say i was afraid at beginning. This is my first OOP project, so i spent some time to find my way. But i am very happy when i see my progress and the results step by step... It will surely not as future rich as Padloper but my clients do not use many futures anyway. Mainly the general things.... Hope to present my first Ecommerce project on PW here soon....

I appreciate the effort here, but remember @kongondo that many of us aren't looking for that full list of features from your original post two years ago. I'd much prefer a performant cut down version and the ability to give you some money for ongoing development than one giant release with all the bells and whistles. MVP > feedback from real customers > new releases. Thanks and i hope everybody is okay considering the current climate =D

Something like this should get you going. This is stolen from a recent import I did which worked well. This assumes you have a field called "images" that you want the images uploaded to. I have also done more complex versions of this when the source HTML image tags have width and height tags - you can use those to resize the images using the PW API and embed that version back into the HTML. $dom = new \DOMDocument(); @$dom->loadHTML(mb_convert_encoding($html, 'HTML-ENTITIES', 'UTF-8')); foreach($dom->getElementsByTagName('img') as $img) { // grab image from the external URL and add to images field try { $np->images->add('http://olddomain.com/' . $img->getAttribute('src')); if($img->getAttribute('alt') != '') { $np->images->last()->description = $img->getAttribute('alt'); } $img->setAttribute('src', $np->images->last()->url()); } catch(\Exception $e) { // in case remote image can't be downloaded } } return preg_replace('/^<!DOCTYPE.+?>/', '', str_replace( array('<html>', '</html>', '<body>', '</body>', '<p>&amp;n<p>', '<p><p>', '</p></p>'), array('', '', '', '', '<p>', '<p>', '</p>'), $dom->saveHTML()));

In my opinion you can build amazing backend web applications with ProcessWire, as I already built some with it. A big difference is, that most frameworks like Laravel do not come with a backend. So you have to use Laravel Nova or Voyager to create a nice looking backend. ProcessWire on the other hand comes with a nice customizable backend. Depending of the type of backend/application you build, you have to "bend" the PW backend to your likings, this includes removing features, or writing modules to get the behaviour you would like (for example restricting users to a branch). In other frameworks you start with "nothing" or a boilerplate and develop the features you like, which might be more work, but you get a very tailored application. You could do this with ProcessWire also, if you like, because you don't have to use the included backend. What I was missing for example in Laravel Voyager were field dependencies, which hides or shows fields depending on the state of another field. One big drawback of ProcessWire is the sync between a live server and your dev server. Because ProcessWire does not distinguish between structural and content pages (or I am not aware of it), updating a live server with changes you made on dev is very cumbersome. There is some discussion about this going on here on the forums: or here