ryan

Looks like they've completely changed it to the point where this module would have to be largely re-written. I'm looking into that. Is anyone already familiar with API v3 of Calendar?

There aren't any connections to the admin theme with this module. But installing AdminThemeReno would have cleared the modules cache, so I'm thinking that's most likely what was needed (a modules refresh). It will go into the core once I can add the option of FTP/SFTP/FTPS installation as an option for upgrading/installing modules and core. Your statement is true with Drumlapress, but not with ProcessWire as far as we know. While newer core versions add new security enhancements and such, running an older version of PW doesn't mean your site isn't safe. If a site is running smoothly and does everything the client wants, I tend to leave it alone. Even if upgrades are relatively safe and easy, there's always a rare chance that something will break and need an update as a result of upgrading the PW core or any module. There are plenty of good reasons to upgrade, but since there are no known security vulnerabilities in past versions as of yet, having a safe site is not currently one of them.

And too bad about WordPress if that's what they are using. I don't think they even know about PW. I will have to have a talk with them sometime.

I used to work there for several years- my first job out of college. I actually designed the website about 2-3 versions before the current one. Though couldn't tell you anything about the current site. I've always missed working there, one of the best places I've worked. Always great to hear about Grafik.

Guys hope you don't mind but this thread is entirely too bizarre, so I'm closing it. There's some good stuff here too, so not going to delete it, but please continue your conversation in a new thread if you want to– just no more name calling, PW death threats or summoning gods. Or if you must, then keep that stuff in the Pub. The general support is not the place for this. -- Edit: just moved this to Pub.

@Chris White, I've replied in the ProFields board.

I'm not so sure about this one because that particular call without an if() statement around it to check if there are any images would be a code error that needs to be fixed. If the error were allowed to continue, the problem might never be fixed. However, if the error were to be suppressed, then it would have to do that by returning some other image. But what image should it return? That should be up to the developer, so we've actually added the option to have it return a default value (image) when no images are present, and this was added specifically for the type situation you describe, where you want image fields to always be "populated" with something even when they aren't. This was added in 2.5 and present on both stable and dev branches and visible on the Image field settings (Setup > Fields). I agree that's a crazy error message that is always a source of confusion. The installer performs all the PHP version checks, but of course if someone moves a site from one server to another and skips the installer, then they might not see the PHP version error message. I'm not sure that PW should be doing a PHP version check on every page load (or maybe it should, have to think about that one a little more). When you saw that particular error message, do you recall where it was originating from (file/line)? If I can isolate the block of code that produced the error, that would be my preference, but if not I suppose a PHP version check on every execution may be necessary.

Nico, I like what you are getting at, but think an option like that might be a source of confusion because it would change the entire way that templates work, as well as the way that viewability is determined. Most likely this would be problematic for PW's internal templates and logic. What I would suggest instead is repurposing of the existing $config->appendTemplateFile option and letting that serve is your defaultTemplateFile. In order to make sure that PW considers your page viewable, you'd still have to have a file for the template, but it could be completely blank. While I'd prefer the method mentioned above, another alternative would be to automatically populate the altFilename property of every template that you wanted to behave this way. For example, in your /site/templates/admin.php file you could add something like this: foreach($templates as $template) { if($template->flags & Template::flagSystem) continue; if($template->filenameExists()) continue; $template->altFilename = 'ajax.php'; $template->save(); }

Languages can't be modules because they are pages, and that's a pretty important aspect of them. Languages are a type of editable content rather code and logic. But it may be possible to have language packs (the translation files) distributed as modules. Language packs are just one component of a Language, but a component that would be useful to behave as a module when it comes to version tracking and installation. I'll look into it.

Didjee, would it be possible for you to try a completely fresh install in another directory? The errors you've mentioned here and in another thread make me think that somehow some old files are present in your copy. Trying out the dev branch would probably be the best bet. I would also be interested to know what your server environment is, beyond PHP and MySQL. Is it running Apache, or something compatible with Apache? Running as a module or CGI/fastcgi?

I've tried to duplicate this one here, but haven't been able to. I've kept the MySQL settings for my dev server at the strictest settings possible for the last month or so, so am thinking that whatever the issue is here, it's probably something different than we've seen elsewhere. Also, so far this is the only report I'm aware of this occurring in the current release version of PW. Since the error is very similar to the one we saw before the MySQL settings issue was fixed, I do wonder if just grabbing a fresh copy of the PW core might be a good idea here. Didjee if you are able to try that, please let me know. You might want to try the dev branch, since that always has the latest updates on it.

Horst, is it possible that the module in question extending FieldtypeImage is overriding its constructor without doing a parent::__construct() ? It doesn't look to be an issue with FieldtypeCropImage, because it doesn't override the __construct(). But you mentioned this is not CropImage, but a fork of it, and the behavior you describe sounds like FieldtypeImage that's being extended is uninitialized (i.e. not having it's constructor called)?

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.