ryan

The notifications are part of the admin. PW doesn't get involved with your front-end output, so it's not attempting to provide anything with regard to notifications on the front-end. However, you can still use the API to add notifications to any user, but they'll need to go to the admin before they will see them, unless you provide your own output code on your front-end. If you wanted to output notifications on the front-end of your site, it would actually be as simple as this: foreach($user->notifications as $no) { echo "<p>$no</p>"; } There are of course several other properties, methods and flags that you can access from the Notification ($no) object. But outputting a notification is basically just a matter of iterating through the $user->notifications field and outputting them all, or just the ones you want. So in this sense, it actually would be quite easy to utilize on the front-end, but like with anything in PW on the front-end, you have to decide how you want the output to be handled. Currently it's using the same method as the forum we're typing in (IP.Board). I have not kept up with websockets technology lately, but was under the impression we weren't there yet unless you had specific client-side and server-side libraries to handle it and provide the fallbacks, or were using node.js, etc. I'd gladly implement websockets in the future if they enable us to accomplish the same thing more efficiently, easily and reliably without bloat. Last I researched this, we weren't there yet, at least in our LAMP context. But you likely know more than I do about that technology at this point, so interested in hearing more.

Soma's right this is still in development, so things may change and it's too early to write up docs. But here's the basic concepts that probably won't change: Display notification on next request (these work whether SystemNotification is installed or not, but the output is of course different): $this->message("Message to display"); $this->warning("Warning to display"); $this->error("Error to display"); If outside of an object context, you'd replace $this with wire(). These notifications (above) have been with ProcessWire since the beginning (except for the warning one). The SystemNotifications module continues the same strategy and extends it. It enables notifications that go beyond just simple "display once on next request" notifications. It also enables you to send notifications to any user, regardless of whether they are logged in (they'll get the notifications when they next login). If the user happens to be logged in, they'll get it immediately–it will pop up on their screen without them even having to load a page. To use these persistent notifications you have to send them to a user ($user = any user): $user->notifications->message("Message to send"); $user->notifications->warning("Warning to send"); $user->notifications->error("Error to send"); $user->notifications->save(); // this is required to commit them They also have a Javascript API, for sending immediate notifications to the current user. These particular notifications do not persist across requests, so they are more like a JS-version of PW's "display once" notifications, except that they display immediately. Notifications.message("Message to send"); Notifications.warning("Warning to send"); Notifications.error("Error to send"); There's actually a lot more to it, as each notification can have various different flags and properties. Notifications that persist across requests can also be modified, which is great for things like progress bars or other kinds of state changes. Further, they can contain any amount of "details" content, even entire HTML blocks. This is all stuff we'll cover once these are finalized.

Thanks for the module Nico! Could you update the GitHub readme to either have instructions like this or link to this page? I mention it just for those folks that might download the module but not know about this thread.

@bbeer that is a lot of fields to have in one template. I also see that it's not just a lot of fields, but most of them are also multi-language, which takes your quantity of fields and multiplies that by the number of languages (4 in your case). Plus take your quantity of individual files and multiply that by 4 as well. It's possible you could be hitting 800+ inputs here. While I don't think this quantity of fields is necessarily a problem, I do think that you should expect some overhead in trying to render and save that many fields at once. It's not just going to be server side, as that's a lot of markup for your browser to process, and a lot of DOM elements for the Javascript client side as well. So you will likely see both server-side and client-side overhead at this scale of fields. I also see some third party modules involved here, and I don't know to what extent they also add overhead. For instance, I see you've got Teppo's awesome version control module on most of your fields. I also use that on my sites. But I've always assumed there must be some significant overhead with it given all the great things it does, so I typically limit usage of it to only 1-2 fields on a template. Unless Teppo says otherwise, I would suggest doing a test and remove the version control from those fields just to see what difference it makes. In fact, the same goes for any 3rd party modules that you've got involved here (I see one active in your files). Remove or change them to non-third party temporarily just to see if you an find any bottlenecks. Sometimes certain bottlenecks only become apparent at larger scale like you have here. One thing that could make a potentially huge difference here would be use of the Textareas ProField field. This is the perfect case for it, since you have so many similarly configured Text and Textarea fields. It looks to me like you could potentially reduce your quantity of fields by a factor of 10 or more, which may solve the overhead issues completely on their own. However, you may lose the version control (which I'm assuming either doesn't work with the Textareas ProField, or treats all the components of it as one block), and you would have to change your multi-language approach slightly by using the language alternate approach with separate language-specific Textareas field. But it would still drastically cut down on the field quantity and thus overhead. Another thing to consider is that it's possible you may be trying to accomplish too much with one page/template here. If you look at it from a database design perspective, it's kind of like having one giant god table that holds everything, rather than splitting it out into specific, more dedicated parts. However, if each of the pages like this is completely different in content (i.e. little to no repetition of what gets populated in the fields), then it may be completely fine. I can't really evaluate much from looking at the screenshots because it's just one page and I don't read the language. So I'd be inclined to see how you can reduce overhead with what you've got before you re-think the structure of it. Lastly, you may have to consider the PHP max_input_vars limit. With ~150 fields multiplied 4 languages, plus quantity of individual files multiplied by 4 languages, you could hit the default limit already. You will likely need your system administrator to bump that limit up from 1000 to 3000 to play it safe. Otherwise you could experience data loss when saving a page.

Whether that will work depends entirely on the load order of the modules. You can affect the load order by making one module require another. However, if the two modules are related, it would be better to simply make the UserFrontendRegister module the only autoload one, and make it call upon the other modules when needed. Conditional autoloads are much better used for things like determining page or template context.

So far I can't duplicate this one. Anyone else able to? @nfil, just to confirm you are talking about Setup > Fields > Add New, and you are entering a field name correct? Because it is true that a field name is required. What modules do you have installed in Modules > Site ?

The emails themselves are pages in ProcessWire as well, so all the content managed just like any other ProcessWire page, i.e. https://processwire.com/about/newsletters/processwire-weekly-22/

It's made 100% in PW and sent directly from this server using PW's WireMail interface with either Teppo's WireMailSwiftMailer or Horst's WireMailSMTP.

Thanks guys! That's very kind of you. I'm officially old now. ProcessWire was also released as an open source project around this time of the year in 2010. While I don't much like having birthdays myself, I do like celebrating ProcessWire's birthday, and looking forward to the big 5-year birthday next year.

Soma, that won't work because that's just a string comparison. You'd need to use PHP's version_compare() function instead. There is also $modules->versionCompare($currentVersion, $requiredVersion, $operator); that achieves the same thing, but accepts version numbers as either strings or integers (and you can mix and match if needed). Of course you could pass through the version for PW or any module to JS anywhere you wanted, via $config->js() or in a data attribute of some markup, etc. I think the need is likely rare though, since requests originate on the PHP side and any version checking is usually better done there. No changes to the permission property, other than that it can now be used on any module type (not limited to just Process modules anymore). Usage is the same as before and it specifies the single permission name needed for PW to execute the module, (i.e. 'permission' => 'widget-edit'). Though there is a 'permissions' property (in 2.5) where you can specify permissions that you want PW to automatically install with your module (and likewise uninstall), i.e. 'permissions' => array(' 'widget-edit' => 'Edit a widget', 'widget-add' => 'Add a widget' ) Your module is responsible for permission checking, outside of the one permission you may have specified in order for the module to be executed. For instance, if you had an executeAdd() method in your module, you might like to do a if(!$this->user->hasPermission('widget-add')) before rendering an "add" button, as well as at the top of your executeAdd() method. Yes, you can throw an exception from either install() or uninstall() to cancel the operation. Though in your scenario, I would usually make the Fieldtype module the parent one (rather than the Process), since it is the one module in your set that may be externally linked (i.e. via fields that are using it).

This issue was fixed in PW 2.4 dev awhile back, so should already be fixed in PW 2.5. Though let me know if you continue to see it in PW 2.5.

Hi Gabe, this module wont work with fields in repeaters because repeaters render their own fields. This module hooks into ProcessPageEdit, which isn't used by repeaters. However, if you need the capability one alternative would be to use PageTable rather than repeaters, as this module should be able to affect the output of PageTable (since it uses ProcessPageEdit).

Logic is too broad a term. There is presentational logic and there is application logic. IMO the logic you want to keep out of the main template is application logic, not presentational logic. If there is presentational logic that applies to most pages in the site, then I really prefer to have it in the main template, or at least include()'d from the main template. It comes down to what's going to simplest to maintain long term. If something presentational needs to be manipulatable by other templates, then of course it should go in it's own placeholder variable. But if it's not, then delaying that output or moving it somewhere else is just more overhead and things to keep track of. This is of course just fine, and everyone's got different methods that work best for them. But I would also suggest that the more markup you can keep in your main template (that's common to most pages) then easier it is to maintain over time. Easy to maintain means different things to different people, so I should qualify that to me "easy to maintain" is when the site-wide markup is in fewer places, fewer files to update, etc. I don't think the holy grail is necessarily eliminating html tags from your template files. That's what I did with the blog profile, sticking to an MVC approach. But I don't find it as maintainable as default site profile intermediate method (maybe for a team, but not for an individual developer). Further, and somewhat to my disappointment, I think most find the blog profile (sticking to an MVC approach) difficult to understand. The fact is that this approach means more files, more things to keep track of. It's the right solution for some cases, but it's no holy grail. I think instead the holy grail is KISS + DRY (keep it simple stupid + do not repeat yourself). If you've got markup going in a template file where the same markup is going in another template file, then put it in a shared function, include file, template/view file or a class/hook or something (I prefer functions myself). If you've got to change something, make sure you only have to change it on 1 place. The end result ends up being most template files have little or no markup, not unlike the MVC blog profile… but a whole lot easier to understand and maintain– you've KISS'd it, minimizing the number of places where markup appears and not adding extra unnecessary overhead and files. The benefits of going further MVC become apparent when you work in a team where the concerns are split along the same lines as the files. In that case, more files is beneficial. The front-end markup girl/guy focuses purely on the view files, and the back-end developer focuses purely on application logic. But if it's not a team project like that, and isn't going to be, then following that approach is kind of like trying to avoid stepping on the seams in a tile floor as you walk across it… Think of "main" as meaning "main" (like primary), not "all". One example of different layouts can be seen in the intermediate profile's _main.php where it adds a has-sidebar class to the body tag when a $sidebar variable has something in it. But there's no requirement that _main.php be used by every template file. You can disable the $config->appendTemplateFile in your /site/config.php and include your own, like Martijn outlined above. Or you can edit your template in the admin: Setup > Templates > [your-template] > Files. Check the box to disable auto-inclusion of _main.php, or specify what file you want it to include instead.

Thanks for the report junofornow. I don't actually think that your change is what fixed it (unless we hear of it occurring to anyone else) because those two calls are equivalent. What's more likely is that there's an opcode cache involved here (like APC or eAccelerator, etc), and your change triggered the opcode cache to clear. I would be curious if you went back and changed it to the $wire->wire() version if the error re-surfaced? I would guess it doesn't, but would be interesting to test.

Glad you figured it out. Unfortunately $_SERVER['SERVER_NAME'] can't always be relied upon because some cases have it populated with something other than the hostname of the current site (like the hostname of the server itself rather than the site). Though you also can't rely on $_SERVER['HTTP_HOST'] either, as that can be manipulated by the request. If you need the capability to automatically switching DB configs depending on dev or live, your best bet is probably to copy your /site/config.php to /site/config-dev.php and only keep that file in your dev environment. Your /site/config.php will be ignored when /site/config-dev.php is present, enabling you to accomplish the same thing you are now, so long as you don't upload config-dev.php to your live site.

You actually do want /site/assets/installed.php to exist, and you don't need /install.php if this is an existing site. Are you sure this server is Apache or 100% Apache compatible? Currently it sounds like it might not be. You'll also want to double check the PHP version. I would try renaming your .htaccess file to htaccess.txt temporarily to see if you get any change in the error message. Do you have an index.config.php (multi-site config file) file in your web root? (I'm assuming not, but just double checking since that adds new layers to the question). If confirmed the server is Apache and PHP version is alright, I would next try looking at the $_SERVER variable. Specifically, paste this into a /oftest.php file and PM me the result: <pre><?php print_r($_SERVER);

That error occurs only if $config->dbName is undefined (from /site/config.php). Usually that's a signal for PW to load install.php (installer) but it was also not found. If you can look in /site/config.php and see that $config->dbName is defined and it's correct, then you'd want to 1) Make sure you don't have a /site/config-dev.php overriding your /site/config.php; and 2) look at whether something is fishy or non-standard with the server paths. The good news is that debugging it doesn't need to go beyond your /index.php because PW is basically not able to load beyond that… the error is coming directly from /index.php.

On a fresh installation, I'm not seeing this issue. Name and Permissions are the defaults if you don't select anything. I'm guessing maybe you had it installed before we had this fully configured, but as far as I can tell it's not an issue anymore. Though let me know if you experience something different on a fresh install. @GuruMeditation thanks for the excellent instructions. I was able to reproduce it easily and likewise fix it easily. The latest version fixes this issue.

@mikelexp thanks for the video and the GitHub issue report. I've not been able to duplicate the issue here, though have tried a few times now duplicating your exact steps in the video and trying out some variations. As a result, I think we need to take a closer look at your installation: 1. What other 3rd party modules are currently installed? 2. On the template used by the parent page where you are adding children, what are the current "family" settings? I'm especially interested in what it says for the "Name format for children" field.

Just to correct the quote above, delayed output is more scalable, not less scalable. Direct output is what doesn't scale, but it doesn't really matter when it comes to the default profile. I have worried about this aspect a little bit: making something as easy-to-understand as possible, versus showing what is a best practice. Delayed output is just as simple as direct output (not to mention it uses a lot less code), but it's not as easy to understand at the very beginning. On one hand the PHP developers evaluating ProcessWire cringe when they see the direct output method used in the old default (now classic) profile. On the other hand, beginners find it easier to relate to since it's common in other platforms. Both are our audience. If people think delayed output isn't beginner friendly enough, perhaps we need to have two versions of the default site profile. A beginner edition and an intermediate edition. Attached is a beginner edition of the default site profile. @Woop if you or anyone else gets a chance to take a look, please do and let me know if you think this is a more beginner friendly approach. I think it probably is, even if it isn't an approach I'd suggest someone use for anything but smaller sites. site-beginner.zip To install, just grab a fresh copy of ProcessWire 2.5.0+. Place the contents of the zip in a /site-beginner/ directory and then load the installer from your browser. For site profile, select "Default (Beginner Edition)". The readme file in /site/templates/ has also been updated in this profile to reflect the structure of the template files. As for re-writing the text in the default profile (something mentioned way earlier) I agree on this and I need to talk to Joss. But I think getting the template files as simple as possible is a bigger priority at the moment. I think a lot of people installing CMSs for evaluation are more interested in the system and templates than in what demo content is in the fields. But for those that do read it, we can do better.

Evan, it's actually not specific to MySQL 5.6 per se, but rather MySQL's sql_mode setting. We're seeing some strict sql_mode settings are a lot more common in MySQL 5.6 than in 5.5. I'm now running with them on my development environment and have fixed a couple spots in the core that were potentially issues with these sql modes. Though I'm not aware of any spots on FormBuilder that were potential issues with these sql modes. You mentioned that you were already running PW 2.5 though, so I honestly don't know what it could be. I've tried to duplicate it locally but so far can't. Can you give me more info on the steps you took and exactly when the error message appeared? It sounded like immediately after creating a form (i.e. entering the form name and clicking submit), but just wanted to confirm?

Wow, awesome site Nico!

Correct me if I'm wrong, but doesn't SHIFT+CMD+V (Mac) or SHIFT+CTRL+V (Windows) force paste as plain text in almost any application? That's the way I've always done it and it generally works well. No need for extra plugins to do this when that capability should already be OS native.

Sorry for my late reply to this. First question here would by why not just select Roles and then choose "newuser" in the select box? It doesn't seem like it's necessary to use custom (field=value) here. However, if you want or need to use custom (field=value) for some reason, then you would need to specify the property of roles that you are trying to match because "roles=" would require an integer of the role ID. I think what you intended was "roles.name=newuser" ? However, I really recommend just choosing "Roles" as your field and then select "newuser". Are you sure that "testuser" session had ended? (i.e. logged out and logged back in?). DynamicRoles caches some information about the user's access within the session (server side) at login. There's no way that the user can change that since it is all server side, but if you are making big changes to the access for a user that's logged in, they may not see those changes till their next session. Or you could clear the server side session files/db to force clearing of the cache. But I'll assume you may have already tried logout/login, so unless I hear back I'll try to duplicate here. I've not been able to duplicate that here, but I do think I know how to fix it. Go to the DynamicRoles module settings and select the fields that should appear in your dynamic roles listing. It looks like you've got Title selected right now, which you don't want (since there is no title for dynamic roles). I would suggest selecting name and permissions. Please let me know if that fixes it?

Actually pretty much everything has been moved to /wire/config.php, leaving /site/config.php exclusively for things that you want to modify from the defaults. You'll notice that /site/config.php pretty much contains nothing now other than debug and the settings added by the installer. However, any config property can still be modified from your /site/config.php file. See the /wire/config.php for a full reference of all possible properties you can customize.