adrian

You can easily make use of PW's $database to call an external database to populate content on a page - nothing fancy and no hooks required. It might help if you can provide more details of the data in these tables and how you want it displayed.

@Beluga - are those massive execution times with BCE or Ryan's module? I am using a third party csv parser - I don't think its approach is very efficient, but php's built-in parser is crap when it comes to certain situations. There might be better options out there though. BCE doesn't make any SQL queries directly so not sure any of those mentioned tweaks would be any use. Also given that in PW each field has its own table I don't know how you could make use of LOAD DATA INFILE etc because you'd have to do a lot of data manipulation before inserting so that you were populating one table at a time with all required data - sounds like a real likelyhood of introducing data integrity problems. That said, if you find something that makes a dramatic difference, please let us know.

I feel like the "quiet" save option should also work for published. It works for created, but not modified or published. This SQL will do the trick though: $sql = "UPDATE `pages` SET `published` = '2015-01-01 12:30:00' WHERE `id` = '2101';"; $database->query($sql);

@Beluga - it sounds like you sorted out your problem with the Import Pages From CSV module, but if you decide to come back to BCE let me know and I'll see what I can do about adding support for no title pages.

I kinda also wonder if that $settings variable should be changed in ListerPro - seems like it should be $listerSettings or something?

I know this is ancient, but I wanted to note that if this worked in the past, it no longer works. I think I recently even saw reference to placing $config->debug = true in ready.php. None of these options work properly. If you want conditional debug mode, you need to use the debugif option: https://github.com/processwire/processwire/blob/35df716082b779de0e53a3fcf7996403c49c9f8a/wire/config.php#L56-L71 Keep in mind that setting it to true in a module or ready.php etc might make it look like it's working because the "Debug Mode Tools" link and icon will appear in the admin, but it will not output any errors/notices/warnings to the browser. Also, in the debug panel you'll notice that the "Database Queries", "Timers", and "Autoload" sections are not populated because they require debug mode to be on Also, of course, with Tracy enabled you don't really need debug mode on (or if you do have it on), it will take care of capturing any errors, and hiding them from users, anyway. The only thing you will be missing with it off, are those "Database Queries", "Timers", and "Autoload" sections.* Anyway, hope that helps to avoid any confusion for those who come here in the future. * This really wasn't meant to be a Tracy advert, but thought it was relevant because it solves the reason why you would want debug mode on only for superusers or the like.

Actually, it's pretty nice running your API call through the Tracy Console - save it as a snippet so you always have it on hand. This way you can easily see the results of the selector as well as the SQL query used to generate them. PS I think this is the thread that was mentioned regarding teppo's version: https://processwire.com/talk/topic/9408-is-there-a-way-to-convert-a-selector-in-sql-using-pw-engine/ although I think it's actually longer.

$page->children("start=2, limit=2") Although I don't really see the reason to do that when css columns make it so easy. Also, rather than that, you should probably do an in memory selector to reduce unnecessary db calls, so: $children = $page->children(); $children->filter("start=2, limit=2"); Also, if you haven't discovered TracyDebugger yet, the console panel is the perfect place to test and learn this stuff:

Ah yes - sorry, my fault about the php modulus approach - you need to count the number of items and divide by three and do a ceil() to make it an integer and use that number because it is breaking on rows and not actually columns. To be honest, I don't really see the point in using the PHP approach these days since css columns is well supported. As for the first column having the dot list-style-type - do you want them all to have dots, or none? It looks like perhaps you have another css rule that is interfering, but I am sure you have that figured out by now.

Yeah, I guess it is very weird that "awe-some" is great, but "aw-ful" is a complete lack awe, or maybe it's full of awe about how bad it is - English is weird!! As for the vertical column order, it seems fine here. Maybe you could show what you are getting and what you expect in case I am misunderstanding.

Not sure if there is a translation problem there, but not typically the way to say thanks If you need to sort, just add: "sort=name" as the selector for children(), eg $page->children("sort=name")

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?