adrian

See my post Modulus operator - note that the style for the ul columns in this example is rough, but you should get the idea how it's done. foreach($page->children() as $i => $item) { if($i%3==0) echo '</ul><ul style="width:150px;float:left">'; echo "<li>{$item->title}</li>"; } echo '</ul>'; CSS Columns echo '<ul>'; foreach($page->children() as $i => $item) { echo "<li>{$item->title}</li>"; } echo '</ul>'; ul { -moz-column-count: 4; -moz-column-gap: 20px; -webkit-column-count: 4; -webkit-column-gap: 20px; column-count: 4; column-gap: 20px; }

Use the "Create Users Batcher" action in the Admin Actions module (https://processwire.com/talk/topic/14921-admin-actions/) .

You can accomplish this in two main ways - PHP via the modulus operator (google php modulus columns) or via css columns.

Have you tried replacing your entire wire folder? Also, what version are you running - I assume 3.x, but perhaps try upgrading to the latest to see if that helps.

FYI: https://github.com/processwire/processwire-issues/issues/187

I know this is a little late and it shouldn't happen when using the built-in front-end editing, but when I use frontend forms that need some core js, like AsmSelect fields, since PW 3, I now need to do this to define "ProcessWire" in js. <script type="text/javascript"> <?php $jsConfig = $config->js(); ?> var ProcessWire = {config: <?php echo json_encode($jsConfig); ?>}; </script>

Hi @valan - any chance I can get a login for the site to take a look?

Hi @ali.donde, I think there might be a little bug in the PW core regarding this. The code is supposed to check the existing value and not try to set it if it's already above the requested value. Unless you are running the iMagick image engine (additional module), then it should only be trying to set it to 30 seconds. If your server is already set to 50, then it should not try to change it. You can see that logic here: https://github.com/processwire/processwire/blob/35df716082b779de0e53a3fcf7996403c49c9f8a/wire/core/ImageSizerEngine.php#L942-L948 I am going to ping in @horst here to see if I am missing something, but until he replies, you can probably get going by commenting out that line 951 that is producing the error. @horst - any thoughts on why this isn't working as expected. Have you ever come across a situation where ini_get('max_execution_time'); doesn't return the correct value? The other possibility might be from this line: https://github.com/processwire/processwire/blob/35df716082b779de0e53a3fcf7996403c49c9f8a/wire/core/ImageSizer.php#L328 It's a different version of the setTimeLimit function that tries to set it via the setOptions method, but that method doesn't actually include a "timeLimit" option in its switch logic: https://github.com/processwire/processwire/blob/35df716082b779de0e53a3fcf7996403c49c9f8a/wire/core/ImageSizerEngine.php#L1047-L1089

or

Absolutely - you will need to forward this onto your hosting provider so that they can remove this restriction.

Hi @ali.donde - welcome to the forums. Sorry, I am in a rush right now, but to help more we will need to know the ajax error. If you click on the Network tab of you dev console and then the Response - have this open before you upload the image and tell us what you get. I expect it's a php Warning, hence the "W"

But at least Tracy would give you a chance to debug and test your code changes on-the-fly and maybe save yourself from becoming a dead bugger! PS - I am not sure how well "bugger" translates to those here from non English colonies For those looking for this, this is the definition you want: http://www.urbandictionary.com/define.php?term=bugger&defid=1454790 and definitely not this one: http://www.urbandictionary.com/define.php?term=bugger&defid=734856

Do you have debug mode turned on in site/config.php ? That .htaccess error in your log looks suspicious.

I wonder if it has anything to do with using a string for the version number? I am switching my modules over to string version numbers as well, so would be good to know if that is the problem?

Hi @theo - this looks related to (https://github.com/adrianbj/ProcessMigrator/issues/4). What commit are you using? Please try this one (two back from current) - https://github.com/adrianbj/ProcessMigrator/tree/3e2121b8fdb68e9d9dc0c6aca8aae75e923a2669 I will likely recreate this module in the future after Ryan fully implements the new core methods for exporting/importing pages http://processwire.com/blog/posts/roadmap-2017/ I just don't have the time to put more effort into the current iteration of this, especially given that future versions should make use of the new core features.

Any chance you are running an old version of the module. That method is no longer used: https://github.com/horst-n/CroppableImage3/blob/e87b602cffbbdd648a48aa7a4975f927ff58f4d7/FieldtypeCroppableImage3/FieldtypeCroppableImage3.module#L80-L81

Sounds like a namespace issue because bootstrapped files don't get run through the file compiler you will either need to add namespace ProcessWire; to the top of the file, or do: $page = new \ProcessWire\Page(); to reference the ProcessWire namespace

Any chance you are running InnoDB on a version of MySQL that doesn't support fulltext indexes. I think it was introduced for InnoDB in 5.6.4

Thanks for the feedback @Macrura - I have often wondered how much use the template path (and template editor) panels were getting. Glad to hear that it helped you out

The custom PHP option in @Robin S' module (http://modules.processwire.com/modules/custom-inputfield-dependencies/) should make this possible.

Another minor (but hopefully useful addition) - you can now use keyboard shortcuts to move between items in the console panel history stack. Back: CTRL+CMD+↑ Forward: CTRL+CMD+↓ The up and down arrows are to mimic unix based terminal history shortcuts. Unfortunately I had to add the CTRL+CMD in there as well because it's hard to find a combination that isn't already used for something else, either by the browser or ACE editor. Anyway, hope you will find it useful for speedy switching back and forward between snippets of code you have recently run.

A few updates to the server type indicator ribbon: It's now possible to display it on the frontend as well. It might seem weird, but on occasion I have been looking at the frontend in the wrong tab (live vs dev) and wondering why my changes aren't doing anything You can now hide the indicator along with the Tracy debug bar when you use the hide icon. Here is the css to use if you'd prefer to have the indicator along the bottom: body::before { content: "[type]"; background: [color]; position: fixed; left: 0; bottom: 0; color: #ffffff; width: 100%; padding: 0; text-align: left; text-indent: 5px; font-weight: 600; text-transform: uppercase; z-index: 29999; font-size: 15px; height: 22px; line-height: 22px; pointer-events: none; } which looks like this rather than the default sidebar. It is of course also fixed so it always visible when you scroll.

Any chance there is a page that is assigned to a template_id that doesn't exist?

Did you check the template id of the repeater template against the template_id specified in the data column in the "fields" table for the repeater field? And of course remember that repeater templates are named: repeater_repeaterfieldname

Here's one example: https://github.com/processwire/processwire/blob/50f2834a0ae2a9f9f2ac53439184ebdc04db2f54/wire/modules/PagePaths.module#L216-L222