sforsman

Why do you feel that it's not the way you should be doing it? The only case where I think there could be a cleaner way is if you only wanted to print a comma separated list of the titles of the items inside the Page-fields. Then you could do <h4>Course Details</h4> <strong>Level:</strong> <?= $page->course_detail_level->implode(", ", "title"); ?><br /> <strong>Category:</strong> <?= $page->course_detail_category->implode(", ", "title"); ?><br /> <strong>Grouping:</strong> <?= $page->course_detail_grouping->implode(", ", "title"); ?><br /> Otherwise, just stick with the loops

The reason for this is that you are setting the divisor and the probability after the execution of the garbage collector has already been decided (in other words, after the execution of session_start()). With Ubuntu your default value for the probability is 0, meaning it will never execute. You need to place those ini_set directives before the session is started. In ProcessWire one way to do this would be wire()->addHookBefore("Session::init", function() { ini_set('session.gc_probability', 1); ini_set('session.gc_divisor', 100); }); You would need to place this inside an autoloading module though. Another way would be setting those inside your .htaccess with php_value session.gc_divisor 100 php_value session.gc_probability 1 (depending on your host, this might not work) Your last resort would be clearing them "manually" by adding this to your _init.php. Well basically you wouldn't even need a hook, you could just execute the code. wire()->addHookAfter("ProcessPageView::finished", function() { $prob = ini_get('session.gc_probability'); $div = ini_get('session.gc_divisor'); $path = ini_get('session.save_path'); $expire = ini_get('session.gc_maxlifetime'); if(rand(1,$div) <= $prob)) { foreach(glob($path.DIRECTORY_SEPARATOR."sess_*") as $file) { if(filemtime($file) <= time() - $expire) unlink($file); } } });

Have you checked site/assets/logs/ if anything is written in the logs there? What happens if you turn debug-mode on in site/config.php and try the same again?

The problem is most likely in the settings of your "artist_membership_level" Page-field. Like WillyC there clearly pointed out. What I would check first would be the settings that define which pages are selectable for the field in question. See the screenshot I have attached, I have highlighted the area that I'm interested in.

@kixe: Thanks for the report. I will look into this with proper time. I did some tests and I couldn't yet repeat your results. The module itself does not change the value in a way that should ever result 40,558 getting converted to 40558. It's a very very odd result to be honest with you, because MySQL should only be aware of the locale in regard of dates and times. It seems very wrong that it would use the dot as a thousands separator, because we are talking about a DECIMAL-field. Which version of MySQL are you using? Are you also absolutely certain that you are using FieldtypeDecimal and InputfieldDecimal (and i.e. not FieldtypeFloat/InputfieldFloat)? And just for the sake of it, are you able to execute SHOW VARIABLES LIKE 'character_set%' and SHOW VARIABLES LIKE 'lc%'? @mr-fan: I'll get back to you after I've updated the module a little

Good morning! Just clearing a few things first. Currently the module does not expect a thousand separator at all - neither does it understand anything about your locale. The module expects only a decimal separator, which is expected to be a dot or a comma. Currently there is no validation support either, so invalid values will be just sanitized - which is a bit brutal. However I am more than glad to implement these features now that I see there's interest for them @kixe: If I understood mr-fan correctly, he would like it to be interpreted as a thousands separator - which it currently is not doing, entering "40.559" would result in "40.56" in the database (if configured to use two-digit decimal precision). This is a good idea. I will provide this feature so that you can give the default option in the module-settings + the possibility to override it in the field-settings. @mr-fan: Thanks a lot for your comments! Just to make sure, you would like the dot in this case to be understood as a thousands separator? So if "40.559" was entered, the module would store "40559.00" in the database (when used with two-digit decimal precision)? And if "40.559,559" was entered, you would like the module to store "40559.56"? Either way I will provide an optional strict validation support, which will be based on the precision and sanitization options defined in the field-settings.

@tobaco: No problem! You can add it into /site/templates/admin.php. This will not affect your frontend output at all, because the admin.php is included only when you are on the admin-site. However it won't really affect your admin-site performance either - it's a very lightweight hook and it's attached only to Page-editing events.

I'm slightly confused because soma's example does not use a Process-module to provide any functionality - it's meant to be used in the frontend of your application - and you mentioned Process-modules and that you are trying to do this on the default PW admin-site? Could you provide us some code so we could get a feeling on what you're trying to do? Also a short description on why you are trying to do this could be helpful as well Edit: I'll already mention this afterall. A good way to implement your own page editing logic on the admin site would be creating a new Process-module, that just extends ProcessPageEdit and overrides the necessary methods. Then you would assign your Edit-controller (page) the template 'admin' and select your own ProcessPageEdit-module (you could even change the default Process-module for page-editing under /Admin/Pages/Edit page). Sometimes it's simpler to just hook into ProcessPageEdit though. But this all depends a lot on what you're trying to do.

Provided an example on this post how to prevent it using hooks. It would be great to have this supported natively though, so such "hacky" tricks wouldn't be needed.

Yes this is possible. However since preventing it is not "natively" supported by ProcessWire, you need to trick it a little bit. This can be done in many ways, but here's one wire()->addHookAfter("ProcessPageEdit::buildForm", function($e) { if(!$this->input->get->modal) return; $form = $e->arguments(0); $field = $this->modules->get('InputfieldHidden'); $field->attr('id+name', 'ProcessPageAdd'); $form->append($field); }); Providing a native way would be very simple since the closing of the dialog is controlled by a single variable called closeOnSave in InputfieldPageTable.js. You could also modify the buttons and whatnot. Also submitting the form in a regular way (e.g. by hitting enter) also prevents the modal from closing. The example I provided tricks the InputfieldPageTable.js to set closeOnSave to false by just adding a hidden field to the form with the ID "ProcessPageAdd" (https://github.com/ryancramerdesign/ProcessWire/blob/576a5d30153f045daa94a136a6ba981650632b26/wire/modules/Inputfield/InputfieldPageTable/InputfieldPageTable.js#L52). Edit: Added a litte more information

@MindFull: Thanks for the updated info, it was enlightening. Is the VPN down more often than their Internet-connection? The reasons behind these questions is that if you need 10+ masters, I would suggest a technique Flickr, for an example, uses. You can actually check their post about it here: http://code.flickr.net/2010/02/08/ticket-servers-distributed-unique-primary-keys-on-the-cheap/ - it's a really simple method If only the VPN-downtime is a problem, you could consider running the ticket-servers on the Internet. If things cannot be reliant on the Internet-connection either, then in my opinion, the simplest solution would be using the same method described in the article above, but just using it locally. Either way, such implementation would require hooking to the saving of new pages and just prefixing all IDs with a prefix assigned for each of the PW-instances (read from the site's wire('config') for an example). A three digit prefix would probably be enough to cover all of the customer's expansion needs (forever). Just an example Corporate instance 1: 100 + <local ticket ID> Corporate instance 2: 101 + <local ticket ID> Branch instance 1: 200 + <local ticket ID> Branch instance 2: 201 + <local ticket ID> ...and so on. This would work without any hacks to PW, because you are allowed to set the ID for new pages. UML, urgh, I feel you there!

@gebeer: No idea

It doesn't matter which PHP-based project you use because the concept stays the same - you still need something running in the background of the server, listening on a socket. If you really want to play using PHP, just use Ratchet. It's a lot more mature (meaning fully documented for an example).

I know what you mean adrian! And I have to admit, I've been in love with meteor.js for quite a while - but they were in alpha and beta for ages and I missed my chances of using it in production

@jordanlev: Commenting quickly on this. You want to use PageTables - you'll love them. They will provide your project the ability to include the product locations and variations on the same page with your product. PageTable-fields have their own template attached to them. In your case, you can probably go ahead and use the existing product-variation and product-location templates. You just create two new PageTable-fields, one for each template and then attach the new fields to your product-template. For more information, check this post for an example https://processwire.com/talk/topic/6417-processwire-profields-table/?p=63119. And don't be mislead by the term "field", these are pretty badass fields.

@pwFoo: WebSockets are an overkill for something like this - they are designed for distributed messaging between multiple concurrent users for web applications that work in real-time. For this same reason, they require a special server designed for the purpose - the best currently being something running on top of node.js (like socket.io), a language which was designed for things like this from the ground up. Erlang would be another choice (it even has a socket.io port). In other words, you cannot handle WebSockets with just Apache and mod_php5. Ok, you could always run a PHP-based WS daemon like Ratchet, in the background, but I'm personally not a fan of PHP-based TCP-daemons. They are good for toying with new concepts though. And yes, I do know about the guy who wrote an SSH2 server with PHP, but still, you and I both probably stick with OpenSSH I don't even see this happening for quite some time because Apache was never designed for this kind of purpose. Neither was PHP.

I think he means that when he does $pages->find($selector)->suhosinRandomTimed(3, "c"), $num will still be "2" and $seed will be "Ymd". Like I explained earlier, this happens because in the given example suhosinRandomTimed() -function, the arguments are not read from the $event-object. Here's an example of a hooked method that would work with arguments as expected function suhosinRandomTimed($event) { $pages = $event->object; $num = $event->arguments("num"); $seed = $event->arguments("seed"); if(!$num) $num = 2; if(!$seed) $seed = "Ymd"; // ... rest of the code here }

@muzzer: You need to retrieve all arguments from the HookEvent-object. ProcessWire will never add any other arguments to the hooked method call. In your case, you can get the passed seed-argument with $event->arguments("seed") or like you noticed, with $event->arguments(0). To implement optional arguments, you can do something like $seed = ($event->arguments("seed") !== NULL) ? $event->arguments("seed") : "Ymd"; If you have any other arguments than $event in the definition of your hooked function, I would remove them for clarity and use the method defined above. Or if you think it's nice to see the default values in the function definition, you need to check if the arguments are set in $event and then overwrite them.

Quick bump for MailChimp PS. Will you be implementing the MailChimp API for syncing the mailing list? If you will be, there's a few things you need to be aware of.

@MindFull A few more questions. The items that are synced, are they only page- and field-related? Or also templates? Are all pages being synced or just a subset of them (i.e. pages with a specific template or parent)? If new fields or templates are added at the branch-office, would they be synced back to the corporate DB? How about modules and their configuration (i.e. the modules-table)? Are they synced from the corporate DB to the branch DBs? Is something else being synced as well, apart from the data/code pulled from Git and the PW-related tables/rows? I want to understand the complete scenario before making any suggestions. In that case, would it be possible to consider locking/disabling branch-writes during this? I will come to my point later. Sorry for my being unclear, I meant that if you consider the average day at the branch office, how many writing operations are there related to the tables that are being synced (e.g. UPDATE/INSERT)? This is obviously related to the previous question. I thought that might be the case, now it makes perfect sense This is a good enough reason! Too early to say yet. I'm glad you liked it! It's a good thing that at least the PW-core doesn't use triggers.

Pretty happy to see how you guys have sorted this out for the OP I'd just like to point out that foreach ($editpage->ad_publish_at as $t) { //ad_publish_at is my timestamps field $editpage->ad_publish_at->remove($t); } ...will be a lot slower than WireArray's removeAll(). The reason for this is that the implementation above causes a scan in the array (you are asking an object to be removed from the array). So while there is a foreach loop inside removeAll(), it's different, because it removes based on the keys of the array (which is faster). Changing the original implementation to foreach ($editpage->ad_publish_at as $k=>$t) { //ad_publish_at is my timestamps field $editpage->ad_publish_at->remove($k); } ...would have the exact same speed as removeAll(). But obviously if you don't need to do anything else to the object, it makes more sense to just use removeAll(). Edit: While I was writing you obviously confirmed this with your benchmark

First a few questions. How probable is it that the VPN is down? When the VPN is down, how long is it usually down? Approximately how many writes are there during the day in the branch-offices? How probable is it that there will be more than 9 offices? Also I'm curious, why have you selected SymmetricDS over Tungsten Replicator? I don't see how this would be a problem when you are using auto_increment_increment and auto_increment_offset. You might have read this but it's a good article nonetheless: http://scale-out-blog.blogspot.fi/2012/04/if-you-must-deploy-multi-master.html

This is not a problem for ProcessWire. There would be multiple ways of implementing that. Check this tutorial for an example https://processwire.com/talk/topic/7548-dual-url-structure-for-categorized-content

One of the key design concepts of ProcessWire is that you can use the same fields in multiple templates. Behind the scenes, the values of a field are always stored in the same table (regardless of the template where it is used). This makes it possible to query based on a field without even having to know in which templates it is used. In this respect, it would be completely ok to have multiple templates. Anyway, to answer your question. You cannot currently create a rule that's based on the parent using the default "Show if" -functionality. Now if you want to use the same template, have you considered making the category a Page-field? You could arrange your tree like this News * News item 1 (Category = Jobs) * News item 2 (Category = Jobs) * News item 3 (Category = Funding) Categories * Jobs * Funding The Category-field of the News-template would be a Page-field, that has it's selectable parents set to "Categories". On the frontend you could easily provide filters by listing the pages under "Categories". Implementing the categories this way you can use the built-in "Show if" -feature.

[php.ini] suhosin.srand.ignore = Off suhosin.mt_srand.ignore = Off OR [.htaccess] php_flag suhosin.mt_srand.ignore Off php_flag suhosin.srand.ignore Off (this might not necessarily work for you)