<?PHP questions that don\\'t need their own thread ?>

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > <?PHP questions that don\\'t need their own thread ?>

«‹›223 »

McGlockenshire: Dec 16, 2005; GOLLOCKS!

v1nce posted:

I think McGlockenshire meant that it was already unit tested so you don't have to roll your own code, then test it. Doctrine has already covered this ground, repeatedly.

Yes, this.

jiggerypokery posted:

I tend to simply version a SQLite db populated with fixtures with a cheeky script to build it, migrate it and populate it for the test suite to use. Don't see the point running data reliant tests without, ya know, data. Mocking dbal seems like a waste of time

And yes, this.

Once you've abstracted away the SQL, creating discardable SQLite databases for testing becomes pretty easy.

# ? Jul 10, 2016 19:05

Adbot: ADBOT LOVES YOU

# ? May 19, 2024 12:53

v1nce: Sep 19, 2004; Plant your brassicas in may and cover them in mulch.

jiggerypokery posted:

I tend to simply version a SQLite db populated with fixtures with a cheeky script to build it, migrate it and populate it for the test suite to use.

Does that scale to multiple developers? Do you have one DB dump that you update, do you just add more dump files, do you split the dumps up? Are they paired close to your tests?

Our biggest problem is that we have lots of developers, and we were using a single SQL dump for our fixture testing. We would end up with conflicting changes to the SQL which are a nightmare to resolve.
We then had the SQL separated and paired with the tests (because multiple bundles), but then you'd have to migrate each dump when you move into that bundle, plus you'd need all the extraneous data (eg. a bundle that provides bolt-on features for another bundle would need both sets of data).

In the end we chose to move to something similar to Doctrine Fixtures because we could manage the fixture data as entities-in-code. If something gets refactored then our IDE can pick that up and it's the responsibility of the developer to un-gently caress the data fixture.
One of the best things we get from this setup is the ability to generate random data (using Faker, seeded-random data generator), which is important for our scalability testing. Want 100,000 users? No problem, we'll generate those users, and we can even generate all the extras to go with them (documents, profiles, security, etc).

jiggerypokery posted:

Don't see the point running data reliant tests without, ya know, data. Mocking dbal seems like a waste of time

Mocking DBAL itself isn't a good way to spend your day, but the ability to mock your Repository (talking Symfony) can be very useful if you're testing a service. It removes the DB itself from the mix, and lets you concentrate on that specific piece of code within the service.
We only usually do that where the service method is critical and we feel a lot happier by having that specific thing tested and verified (security, deleting, etc).

# ? Jul 11, 2016 01:14

jiggerypokery: Feb 1, 2012; ...But I could hardly wait six months with a red hot jape like that under me belt.

v1nce posted:

In the end we chose to move to something similar to Doctrine Fixtures because we could manage the fixture data as entities-in-code. If something gets refactored then our IDE can pick that up and it's the responsibility of the developer to un-gently caress the data fixture.
One of the best things we get from this setup is the ability to generate random data (using Faker, seeded-random data generator), which is important for our scalability testing. Want 100,000 users? No problem, we'll generate those users, and we can even generate all the extras to go with them (documents, profiles, security, etc).

We actually do all this, yes. It just populates a sqlite.db file. A .bak is taken and that is versioned.

A cheeky one of these in your bootstrap file for your test suite is lovely.

code:

copy("/var/www/our-people-api/app/sqlite.db.cache.bak",  "/var/www/our-people-api/app/sqlite.db.cache");

v1nce posted:

Does that scale to multiple developers? Do you have one DB dump that you update, do you just add more dump files, do you split the dumps up? Are they paired close to your tests?

Our biggest problem is that we have lots of developers, and we were using a single SQL dump for our fixture testing. We would end up with conflicting changes to the SQL which are a nightmare to resolve.
We then had the SQL separated and paired with the tests (because multiple bundles), but then you'd have to migrate each dump when you move into that bundle, plus you'd need all the extraneous data (eg. a bundle that provides bolt-on features for another bundle would need both sets of data).

Just one works fine for us. If you are using something like jenkins you could run a script like this pre-build

code:

rm app/sqlite.db.cache
app/console cache:clear --env=test
app/console doctrine:schema:update --env=test --force
app/console doctrine:fixtures:load --env=test --append
app/console ourpeople:tag:recipients --env=test
cp app/sqlite.db.cache app/sqlite.db.cache.bak
git add app/sqlite.db.cache.bak
git commit --amend

Assuming you are never merging into dev/master without a passing suite or whatever I can't really see why the .bak should ever conflict. People should understand rebasing their work before making a PR etc anyway.

# ? Jul 11, 2016 14:17

spiritual bypass: Feb 19, 2008; Grimey Drawer

Am I the only one coming to the conclusion that frameworks aren't useful? It seems like Symfony or Laravel expect the programmer to use a whole bunch of code they don't understand to provide features they don't always need. I feel like I can get much better results by pulling together my own libraries for database interactions, routing, authentication, and whatever else. All the frameworks seem to give me is a clumsy installation process and the threat of being forced to migrate away if the framework ever dies.

# ? Jul 13, 2016 18:35

bigmandan: Sep 11, 2001; lol internet; College Slice

rt4 posted:

Am I the only one coming to the conclusion that frameworks aren't useful? It seems like Symfony or Laravel expect the programmer to use a whole bunch of code they don't understand to provide features they don't always need. I feel like I can get much better results by pulling together my own libraries for database interactions, routing, authentication, and whatever else. All the frameworks seem to give me is a clumsy installation process and the threat of being forced to migrate away if the framework ever dies.

It depends. If you have existing libraries for routing, authentication, etc... that are well tested, use that. If you're working on a team with individuals of varying skill levels, having a framework, it's documentation and large collections of tutorials and videos is really useful. "expecting the programmer to use stuff they don't understand" is a rather silly argument. Of course you're going to want to read the documentation or inspect the source and see how it all works, otherwise you're just going to make things more painful for yourself. If you already have a collection of libraries that work for you, it's probably going to seem like a waste of time learning a framework, but for someone new or someone unsatisfied with what they have, why re-invent the wheel?

I'm not sure about Symfony, but I'd hardly call Laravel's setup clumsy now. Maybe in the 3.x and early 4.x versions, but not now.

# ? Jul 13, 2016 19:22

revmoo: May 25, 2006; #basta

With bigger apps you're always going to evolve into a framework anyway.

So you're better off starting with one that was designed from the ground up rather than an evolutionary mess passed down from developer to developer as people join and leave the company over the years.

# ? Jul 13, 2016 20:42

v1nce: Sep 19, 2004; Plant your brassicas in may and cover them in mulch.

rt4 posted:

Am I the only one coming to the conclusion that frameworks aren't useful? It seems like Symfony or Laravel expect the programmer to use a whole bunch of code they don't understand to provide features they don't always need.

I have felt this way. I do not feel this way anymore. I likely would not dream of rolling my own framework for anything non-trivial providing one exists with a modicum of features that make reasonable sense at first glance. On any language.

rt4 posted:

I feel like I can get much better results by pulling together my own libraries for database interactions, routing, authentication, and whatever else. All the frameworks seem to give me is a clumsy installation process and the threat of being forced to migrate away if the framework ever dies.

Just because the framework is dead doesn't mean you have to migrate. Symfony, Zend and Laravel aren't going anywhere any time soon. Chances are that security concerns will be identified which may affect you, and you'll have to upgrade and move forward. This is true of PHP as a whole (get off 5.5 its EOL!) and not just the frameworks. Web is always evolving, and you probably can't write code that'll never change.

Learning (googling, usually) is easier than discovering a problem and writing the framework bits to get rid of it. Often all the features you could ever want are already accounted for in some manner, and if they're not then it's totally possible to crowbar them in.
A mature framework or library is a lot more powerful than whatever you can hope to come up with inside your time allotment. Symfony itself excels at this, with almost all components being interchangable (interfaces!), so if you need to make some magical extra functionality you can just replace/extend the base Symfony classes and tell the service container to use X instead of Y.

If you work for a company and it's affordable then the best head-start with the framework is to hire someone who knows it already, even just as a consultant. This is then your go-to guy for a few weeks, and you provide them every "I have X, I want to Y" problem, and they tell you how it should be done. Often finding the solution to a problem in a framework is as simple as knowing what term to Google. The truly unsupported stuff can usually be solved with some clever patterns.

Frameworks do evolve and sometimes their evolution is not backwards compatible (Symfony, and especially Angular if you work in the JS SPA space). This isn't the end of the world, but some adaptation is required, and it's often done to fix some very serious, very real problems. If at this time you choose to diverge from the original framework, that's fine too.

The double edged sword of frameworks is security; a vulnerability discovered in an open-source framework can be lethal if you don't stay up to date and are still rocking vulnerable libs (see Drupal, JWT). But there's no reason to believe your hand-rolled application isn't peppered with security problems you just haven't discovered (see TalkTalk, Tesco). Security-by-obscurity is only effective when the invisible security hole is small. Having the framework be open is a great way to get peer-review before the code ever makes it to production.

Your own framework implementations make sense because they fit you and you know how they work. Frameworks like Symfony are huge, and they're that way for some very good reasons which might not apply to you.
I've been working on Symfony for around 3 years and there are parts of the codebase I have never looked into, but I use on a daily basis. That's the sign of a good code; interfaces that abstract the problem so that I both never have to dig into the implementation, and updates never require the interface to change.

You're obviously already down the path of using your own framework, and that's OK too, providing you can justify the learning curve for ever developer who will need to use it in the future. I wouldn't recommend changing to another framework from here because you already have established practices and knowledge, and you'd have to un-learn, learn, and migrate, which means being dead-in-the-water for likely a few months. There's nothing stopping you from using the contents of frameworks though; Symfony is built from the ground-up as component based, and lots of the things can just be plugged in to any framework (translator, console, event dispatcher, forms, routing, serializer, validator, etc). If you happen to find your hand-rolled code isn't cutting it, you can always shunt some of the responsibilities over to the framework libraries.

# ? Jul 14, 2016 06:35

Bob Morales: Aug 18, 2006; ~~Just wear the fucking mask, Bob~~

I don't care how many people I probably infected with COVID-19 while refusing to wear a mask, my comfort is far more important than the health and safety of everyone around me!

"Do you want to write an app, or do you want to write framework?"

# ? Jul 14, 2016 13:17

bigmandan: Sep 11, 2001; lol internet; College Slice

v1nce posted:

I have felt this way. I do not feel this way anymore. I likely would not dream of rolling my own framework for anything non-trivial providing one exists with a modicum of features that make reasonable sense at first glance. On any language.

Just because the framework is dead doesn't mean you have to migrate. Symfony, Zend and Laravel aren't going anywhere any time soon. Chances are that security concerns will be identified which may affect you, and you'll have to upgrade and move forward. This is true of PHP as a whole (get off 5.5 its EOL!) and not just the frameworks. Web is always evolving, and you probably can't write code that'll never change.

Learning (googling, usually) is easier than discovering a problem and writing the framework bits to get rid of it. Often all the features you could ever want are already accounted for in some manner, and if they're not then it's totally possible to crowbar them in.
A mature framework or library is a lot more powerful than whatever you can hope to come up with inside your time allotment. Symfony itself excels at this, with almost all components being interchangable (interfaces!), so if you need to make some magical extra functionality you can just replace/extend the base Symfony classes and tell the service container to use X instead of Y.

If you work for a company and it's affordable then the best head-start with the framework is to hire someone who knows it already, even just as a consultant. This is then your go-to guy for a few weeks, and you provide them every "I have X, I want to Y" problem, and they tell you how it should be done. Often finding the solution to a problem in a framework is as simple as knowing what term to Google. The truly unsupported stuff can usually be solved with some clever patterns.

Frameworks do evolve and sometimes their evolution is not backwards compatible (Symfony, and especially Angular if you work in the JS SPA space). This isn't the end of the world, but some adaptation is required, and it's often done to fix some very serious, very real problems. If at this time you choose to diverge from the original framework, that's fine too.

The double edged sword of frameworks is security; a vulnerability discovered in an open-source framework can be lethal if you don't stay up to date and are still rocking vulnerable libs (see Drupal, JWT). But there's no reason to believe your hand-rolled application isn't peppered with security problems you just haven't discovered (see TalkTalk, Tesco). Security-by-obscurity is only effective when the invisible security hole is small. Having the framework be open is a great way to get peer-review before the code ever makes it to production.

Your own framework implementations make sense because they fit you and you know how they work. Frameworks like Symfony are huge, and they're that way for some very good reasons which might not apply to you.
I've been working on Symfony for around 3 years and there are parts of the codebase I have never looked into, but I use on a daily basis. That's the sign of a good code; interfaces that abstract the problem so that I both never have to dig into the implementation, and updates never require the interface to change.

You're obviously already down the path of using your own framework, and that's OK too, providing you can justify the learning curve for ever developer who will need to use it in the future. I wouldn't recommend changing to another framework from here because you already have established practices and knowledge, and you'd have to un-learn, learn, and migrate, which means being dead-in-the-water for likely a few months. There's nothing stopping you from using the contents of frameworks though; Symfony is built from the ground-up as component based, and lots of the things can just be plugged in to any framework (translator, console, event dispatcher, forms, routing, serializer, validator, etc). If you happen to find your hand-rolled code isn't cutting it, you can always shunt some of the responsibilities over to the framework libraries.

You explained this much better than I did/could!

One thing I noticed when using a framework, is it forced me to write my business logic stuff in such way that it's essentially it's own library. This has worked out well as some of our older projects needed the new code and it was pretty painless to backport it over.

# ? Jul 14, 2016 15:50

Scaramouche: Mar 26, 2001; SPACE FACE! SPACE FACE!

I upgraded our php on an old, old, property and right away the logs were full of:
Automatically populating $HTTP_RAW_POST_DATA is deprecated and will be removed in a future version. To avoid this warning set 'always_populate_raw_post_data' to '-1'

So I duly set always_populate_raw_post_data=-1 in my custom php.ini in root, but the error kept happening on each page load. Feeling suspicious, I used phpinfo to confirm that was the ini that was loading. Sure enough, the path had changed!

My old php.ini for 5.4 was in /home/accountname/public_html/php.ini

My new php.ini (that phpinfo is reporting) is in /opt/php56/lib/php.ini

And the "Scan this dir for ini files" and "Additional ini files parsed" entries are both blank.

I'm using HostGator running traditional cPanel, and for obvious reasons I can't access the /opt/ folder from File Manager/FTP (no shell access). I've determined that HostGator has a "php.ini editor" that lets you change values in a form field kind of way, but the always_populate and scan for additional options aren't there to be changed. Any hardcore php heads out there know how to get around this?

EDIT-Adoy leaving question up to show how dumb I am. Change one option in the php.ini form field editor, it'll copy a new php.ini to your /home/ folder that you can now mess around with to your heart's content.

Scaramouche fucked around with this message at 21:09 on Jul 18, 2016

# ? Jul 18, 2016 21:05

McGlockenshire: Dec 16, 2005; GOLLOCKS!

always_populate_raw_post_data is one of the settings you can override in an .htaccess with something like:

php_value always_populate_raw_post_data -1

But, before you do that, make sure that the code isn't actually using $HTTP_RAW_POST_DATA for anything useful. If it is being used, then you need to fix that before turning it off or your poo poo will break. the manual suggests reading from php://input instead. You might be able to do something stupid like

PHP code:

<?php
global $HTTP_RAW_POST_DATA;
$HTTP_RAW_POST_DATA = file_get_contents('php://input');

Keep in mind this is a minor waste of time and memory, and I'm not sure what'll happen if you try to read from php://input and there's nothing there. (Reading from it at the CLI will prompt for user input, for example...)

# ? Jul 18, 2016 21:15

Scaramouche: Mar 26, 2001; SPACE FACE! SPACE FACE!

Yeah I did regex/grep long before trying to fix the error to see if I could get rid of it by hand. The only hits were isset/isempty mitigations exactly like the one you had posted.

# ? Jul 18, 2016 21:25

Agrikk: Oct 17, 2003; Take care with that! We have not fully ascertained its function, and the ticking is accelerating.

This is an AWS / DynamoDB question using PHP, so I'll try here first:

I am working on a PHP script that will load a million rows from a tab delimited text file into DynamoDB every hour. I have worked my way through putItem and batchWriteItem and am now trying to figure out how to make WriteRequestBatch work.

The relevant bit of code I have is:

code:

require 'c://php\sdk\aws-autoloader.php';

use Aws\DynamoDb\DynamoDbClient;
$client = DynamoDbClient::factory(array(
    'profile' => 'default',
    'region'  => 'us-west-2',
    'version' => 'latest'
));
use Aws\DynamoDb\WriteRequestBatch;
$putBatch = WriteRequestBatch::factory($client);

with the $putbatch line coming straight from the AWS documentation here.

When I run this code I receive the following error:

code:

Fatal error: Call to undefined method Aws\DynamoDb\WriteRequestBatch::factory()

Clearly I am doing something wrong but I am not knowledgeable enough with classes, factories and whatnot to make any sense of this error. Can someone help?

# ? Jul 20, 2016 22:23

spiritual bypass: Feb 19, 2008; Grimey Drawer

Well, what's inside the WriteRequestBatch class? Does that method exist? Is there another one with a similar name?

Example code is pretty much always wrong somehow.

# ? Jul 21, 2016 01:54

jiggerypokery: Feb 1, 2012; ...But I could hardly wait six months with a red hot jape like that under me belt.

rt4 posted:

Am I the only one coming to the conclusion that frameworks aren't useful? It seems like Symfony or Laravel expect the programmer to use a whole bunch of code they don't understand to provide features they don't always need. I feel like I can get much better results by pulling together my own libraries for database interactions, routing, authentication, and whatever else. All the frameworks seem to give me is a clumsy installation process and the threat of being forced to migrate away if the framework ever dies.

I don't think you are alone, but I'd argue it is probably a wrong conclusion. The whole point of a language like PHP is to get business logic into production as quick as possible and, once there, maintained as cheaply as possible. Frameworks are basically there to provide opinionated shortcuts for you to take to get your ideas to your customers. The key part is opinionated, some like Symfony are more opinionated than things like FatFree. If you want the latter, but want to lesson the risk of migration away go with something like Silex.

The main frameworks are going nowhere, and instillation is basically irrelevant in terms of the lifespan of a project.

Not using a framework doesn't mean re-inventing the wheel necessarily, but when you think about consumer hardware companies they don't all produce all their own chips. An iPhone uses chips supplied by dozens of companies. Building everything ground up is just a waste of time and money.

By the time you've finished making all your libraries, you've basically become the sole maintainer of your own framework.

Agrikk posted:

code:

require 'c://php\sdk\aws-autoloader.php';

use Aws\DynamoDb\DynamoDbClient;
$client = DynamoDbClient::factory(array(
    'profile' => 'default',
    'region'  => 'us-west-2',
    'version' => 'latest'
));
use Aws\DynamoDb\WriteRequestBatch;
$putBatch = WriteRequestBatch::factory($client);

I'm not using dynamo DB but on the version of the AWS SDK I have on this project Aws\DynamoDb\WriteRequestBatch doesn't exist. The class you want is;

use Aws\DynamoDb\Model\BatchRequest;

I highly recommend using PHPStorm. It will highlight when you are importing classes that don't exist etc for you and show potential errors that might have ambiguous messages. You can get plugins or whatever for sublime etc but honestly, my life got so much easier when I made the switch.

jiggerypokery fucked around with this message at 10:37 on Jul 21, 2016

# ? Jul 21, 2016 10:31

Bob Morales: Aug 18, 2006; ~~Just wear the fucking mask, Bob~~

I don't care how many people I probably infected with COVID-19 while refusing to wear a mask, my comfort is far more important than the health and safety of everyone around me!

Am I missing something obvious as to why a few of these line breaks work but the others dont?

code:

238         $report .= "OpenCart Customer ID: " . $customer_id . "<br>\r\n";
239         $report .= "OpenCart Customer Name: " . $customer_name . "<br>\r\n";
240         $report .= "BillTo: " . $bill_to . "<br>\r\n";
241         $report .= "OpenCart Order ID: " . $order_id . "<br>\r\n";
242         $report .= "ShipVia: " . $shipVia . " (" . $shipViaDesc . ")<br>\r\n";
243         $report .= "Order ID: " . $h_id['ordNbr'] . "<br>\r\n";
244         $report .= "PO: " . $po . "<br>\r\n";
245         $report .= "Order Comments: " . $order_comments . "<br>\r\n";
246         $report .= "Date: " . date('Y-m-d H:i:s') . "<br><br>\r\n\r\n";

Output is:

Starting Order Import... OpenCart Customer ID: 48 OpenCart Customer Name: ABC ENTERPRISES LLC BillTo: 44252 OpenCart Order ID: 4395 ShipVia: 37 (BEST WAY) Order ID: 645717 PO: SJ072212 Order Comments: Date: 2016-07-22 16:45:06 Order Import complete.

Line 239 it works, 245 it doesn't. I would guess it might be something in the variable that gets passed in. Notice that it's not escaped, I should do a SQL injection test :cry:

# ? Jul 25, 2016 14:58

spiritual bypass: Feb 19, 2008; Grimey Drawer

Since you're apparently not getting any errors, $order_comments is probably just an empty string, right? Do you have any reason to expect something different?

spiritual bypass fucked around with this message at 15:17 on Jul 25, 2016

# ? Jul 25, 2016 15:05

Bob Morales: Aug 18, 2006; ~~Just wear the fucking mask, Bob~~

I don't care how many people I probably infected with COVID-19 while refusing to wear a mask, my comfort is far more important than the health and safety of everyone around me!

rt4 posted:

Since you're apparently not getting any errors, <pre>$order_comments</pre> is probably just an empty string, right? Do you have any reason to expect something different?

Yes, that string is optional and is empty in that case. Is there a reason you are singling that one out?

# ? Jul 25, 2016 15:06

nielsm: Jun 1, 2009

Bob Morales posted:

Line 239 it works, 245 it doesn't. I would guess it might be something in the variable that gets passed in. Notice that it's not escaped, I should do a SQL injection test

Line 239 and 240 seem to me to be the broken ones? Based on the example output.

Maybe try copy-pasting the whole "<br>\r\n" string from a working line to a broken one, to fix if there may be some invisible Unicode characters or whatever in the middle.

Otherwise try var_dump()'ing the strings, that should also reveal if they have odd things in them.

# ? Jul 25, 2016 15:13

v1nce: Sep 19, 2004; Plant your brassicas in may and cover them in mulch.

Bob Morales posted:

Line 239 it works, 245 it doesn't. I would guess it might be something in the variable that gets passed in. Notice that it's not escaped, I should do a SQL injection test

Yeah I'm not seeing this at all. If I copy everything you put here and provide my own dummy data, it looks perfectly fine.

One of two things is going on:
1. After you've generated your output, but before it actually hits it's destination, your content is getting modified (unlikely).
2. Your data contains something that's messing with the line breaks.

Looks like you're using the <br> for line breaks and NOT the \r\n. There's a good chance there's a control character in there somewhere (something that'll disrupt the HTML).
It's best to always do "View source" on the page if your output looks funky. The raw source will let you see if any dodgy HTML is present. You can't use the browser's inspector for this, as it's usually been safe-ified and sanitised already.

There's also a much better pattern for outputting data like this.

code:

// Collect data fields
$fields = [];
$fields[] = ['label' => 'OpenCart Customer ID', 	'value' => $customer_id];
$fields[] = ['label' => 'OpenCart Customer Name', 	'value' => $customer_name];
$fields[] = ['label' => 'BillTo', 			'value' => $bill_to];
$fields[] = ['label' => 'OpenCart Order ID', 		'value' => $order_id ];
$fields[] = ['label' => 'Order ID', 			'value' => $h_id['ordNbr'] ];
$fields[] = ['label' => 'ShipVia', 			'value' => $shipVia . "(" . $shipViaDesc . ")" ];
$fields[] = ['label' => 'PO', 				'value' => $po ];
$fields[] = ['label' => 'Order Comments', 		'value' => $order_comments  ];
$fields[] = ['label' => 'Date', 			'value' => date('Y-m-d H:i:s') ];

// Sanitise and compact
$lines = [];
foreach ($fields as $field) {

	$value = $field['value'];
	$value = htmlspecialchars($value);
	
	$lines[] = sprintf("%s: %s", $field['label'], $value);
}

// Line breaks
$output = implode("<br/>\r\n", $lines);
echo $output;

More code, but easier to maintain, it's easy to do your sanitisation prior to output, and your field format and line breaks are ensure to always be the same format.

In addition to what nielsm said, you can just var_dump() the content of $fields to check what everything is set to, rather than picking your way through individual vars.

v1nce fucked around with this message at 01:08 on Jul 26, 2016

# ? Jul 26, 2016 01:02

Agrikk: Oct 17, 2003; Take care with that! We have not fully ascertained its function, and the ticking is accelerating.

Agrikk posted:

This is an AWS / DynamoDB question using PHP, so I'll try here first:

I am working on a PHP script that will load a million rows from a tab delimited text file into DynamoDB every hour. I have worked my way through putItem and batchWriteItem and am now trying to figure out how to make WriteRequestBatch work.

The relevant bit of code I have is:
code:
require 'c://php\sdk\aws-autoloader.php';

use Aws\DynamoDb\DynamoDbClient;
$client = DynamoDbClient::factory(array(
    'profile' => 'default',
    'region'  => 'us-west-2',
    'version' => 'latest'
));
use Aws\DynamoDb\WriteRequestBatch;
$putBatch = WriteRequestBatch::factory($client);
with the $putbatch line coming straight from the AWS documentation here.

When I run this code I receive the following error:
code:
Fatal error: Call to undefined method Aws\DynamoDb\WriteRequestBatch::factory()
Clearly I am doing something wrong but I am not knowledgeable enough with classes, factories and whatnot to make any sense of this error. Can someone help?

For posterity:

The answer was that while SDK v2's Aws\DynamoDb\Model\BatchRequest\WriteRequestBatch had a factory method, v3's Aws\DynamoDb\WriteRequestBatch does not. I replaced the r line calling that method with this:

code:

$putBatch = new WriteRequestBatch($client);

# ? Jul 26, 2016 01:18

Scaramouche: Mar 26, 2001; SPACE FACE! SPACE FACE!

Oh yeah btw opencart is kind of gross

# ? Jul 26, 2016 03:06

v1nce: Sep 19, 2004; Plant your brassicas in may and cover them in mulch.

Scaramouche posted:

Oh yeah btw opencart is kind of gross

Compared to PrestaShop it is a gleaming diamond.

# ? Jul 26, 2016 03:57

jiggerypokery: Feb 1, 2012; ...But I could hardly wait six months with a red hot jape like that under me belt.

Did anyone see this? https://www.evonide.com/how-we-broke-php-hacked-pornhub-and-earned-20000-dollar/

quote:

It all started by auditing Pornhub, then PHP and ended in breaking both�

tl;dr:
We have gained remote code execution on pornhub.com and have earned a $20,000 bug bounty on Hackerone.
We have found two use-after-free vulnerabilities in PHP�s garbage collection algorithm.
Those vulnerabilities were remotely exploitable over PHP�s unserialize function.
We were also awarded with $2,000 by the Internet Bug Bounty committee (c.f. Hackerone).

I love postmortems.

quote:

You should never use user input on unserialize. Assuming that using an up-to-date PHP version is enough to protect unserialize in such scenarios is a bad idea. Avoid it or use less complex serialization methods like JSON.

# ? Jul 26, 2016 12:22

Heskie: Aug 10, 2002

v1nce posted:

Compared to PrestaShop it is a gleaming diamond.

Can confirm

Still waiting on a modern mid-level e-commerce platform for general use. There's a couple on the way, but who knows if they'll see the light of day.

Right now its much easier to get a Laravel store up and running than trying to bend PrestaShop to my will.

# ? Jul 26, 2016 12:57

Bob Morales: Aug 18, 2006; ~~Just wear the fucking mask, Bob~~

I don't care how many people I probably infected with COVID-19 while refusing to wear a mask, my comfort is far more important than the health and safety of everyone around me!

Scaramouche posted:

Oh yeah btw opencart is kind of gross

I didn't write this, but it works ($3m/year goes through it). It just jams orders into our ERP system, there's no sales tax calculation, imports don't quite work 10-15% of the time, there's no real-time inventory...we're switching over to a whole new ERP system this fall with an honest-to-god actual shopping cart built in. So happy.

v1nce posted:

Yeah I'm not seeing this at all. If I copy everything you put here and provide my own dummy data, it looks perfectly fine.

After looking at it again this morning, there was nothing wrong with it - it was Outlook 'being helpful'

quote:

There's also a much better pattern for outputting data like this.

code:

// Collect data fields
$fields = [];
$fields[] = ['label' => 'OpenCart Customer ID', 	'value' => $customer_id];
$fields[] = ['label' => 'OpenCart Customer Name', 	'value' => $customer_name];
$fields[] = ['label' => 'BillTo', 			'value' => $bill_to];
$fields[] = ['label' => 'OpenCart Order ID', 		'value' => $order_id ];
$fields[] = ['label' => 'Order ID', 			'value' => $h_id['ordNbr'] ];
$fields[] = ['label' => 'ShipVia', 			'value' => $shipVia . "(" . $shipViaDesc . ")" ];
$fields[] = ['label' => 'PO', 				'value' => $po ];
$fields[] = ['label' => 'Order Comments', 		'value' => $order_comments  ];
$fields[] = ['label' => 'Date', 			'value' => date('Y-m-d H:i:s') ];

// Sanitise and compact
$lines = [];
foreach ($fields as $field) {

	$value = $field['value'];
	$value = htmlspecialchars($value);
	
	$lines[] = sprintf("%s: %s", $field['label'], $value);
}

// Line breaks
$output = implode("<br/>\r\n", $lines);
echo $output;

More code, but easier to maintain, it's easy to do your sanitisation prior to output, and your field format and line breaks are ensure to always be the same format.

Yea, that would be a better way to do it. I love piles of string concat!

I have re-factored quite a bit of code in here, I could probably spend a week on it. Personal favorite was for all these email notifications, instead of just doing

code:

$recipients = array('bob@abc.com', 'tom@abc.com', 'orders@abc.com')

they did

code:

$to = 'orders@abc.com'
$cc = 'bob@abc.com, [email]tom@abc.com[/email]'

Like 500 loving times. So when Tom quit...

# ? Jul 26, 2016 13:46

McGlockenshire: Dec 16, 2005; GOLLOCKS!

jiggerypokery posted:

Did anyone see this? https://www.evonide.com/how-we-broke-php-hacked-pornhub-and-earned-20000-dollar/

I love postmortems.

quote:
You should never use user input on unserialize. Assuming that using an up-to-date PHP version is enough to protect unserialize in such scenarios is a bad idea. Avoid it or use less complex serialization methods like JSON.

To be very clear, the rule about not passing user input to unserialize has been best security practice for over a decade. This is just the latest in a series of avoidable problems caused by opening up internal data structures to end users, one of the most stupid things you can do from a security point of view.

# ? Jul 26, 2016 15:58

spiritual bypass: Feb 19, 2008; Grimey Drawer

"Let's serialize this object and insert it into the database instead of making our database schema conform to our object model"

# ? Jul 26, 2016 16:07

Scaramouche: Mar 26, 2001; SPACE FACE! SPACE FACE!

I know it's not perfect, or even desirable, but I've been consistently impressed by WooCommerce after working with either hand-rolled systems I wrote myself, or "big" name solutions (Magento, BigCommerce, NetSuite, Shopify, etc.). I didn't set out to do so, but I've converted three Open Cart shops to WooCommerce this year. The downside of Woo is that it's free (support could be better), extremely basic functionality is gated behind paid plugins (e.g. brand names, payment gateways), and that it uses the completely retarded Wordpress database structure.

# ? Jul 26, 2016 18:29

Heskie: Aug 10, 2002

Yeah I've toyed with the idea of WooCommerce a couple of times, and been surprised by it, but chickened out as I assume its going to be a maintainability nightmare.

Stuff like Roots Bedrock make WordPress a lot better (using composer for plugins etc), but its still WordPress at its core and comes with all that baggage (DB Schema, security holes, insistence on PHP 5.2 support).

# ? Jul 27, 2016 12:55

Scaramouche: Mar 26, 2001; SPACE FACE! SPACE FACE!

Yeah. Maintenance has been fine so far, but I would never use a Woo install on anything more than say.... 1000 products. At that point you're going to want to use direct database access to maintain stock levels/pricing since anything db-related in WP that affects more than 100 rows runs like an emphysemic marathon man. I'm pretty sure it doesn't require 5.2 anymore though; last install I did it actually warned me for having less than 5.6.

# ? Jul 27, 2016 19:10

McGlockenshire: Dec 16, 2005; GOLLOCKS!

Scaramouche posted:

I would never use a Woo install on anything more than say.... 1000 products. At that point you're going to want to use direct database access to maintain stock levels/pricing since anything db-related in WP that affects more than 100 rows runs like an emphysemic marathon man.

TIL that WooCommerce has a comprehensive REST API.

Do you suspect/know if the scaling issue you're talking about would apply to the API as well?

I guess my weekend project is going to be playing with making a frontend for this stuff.

# ? Jul 27, 2016 19:27

Scaramouche: Mar 26, 2001; SPACE FACE! SPACE FACE!

I'm actually not sure; I'm assuming the API has the same problem since every solution I've tried (e.g. WP Import All, WP XML Import, etc. etc.) all have the same bottleneck/timeout/out of RAM problems

# ? Jul 27, 2016 22:31

spiritual bypass: Feb 19, 2008; Grimey Drawer

That's what happens when you use an entity-attribute-value table instead of a real database design

# ? Jul 28, 2016 03:24

Golbez: Oct 9, 2002; 1 2 3!
If you want to take a shot at me get in line, line
1 2 3!
Baby, I've had all my shots and I'm fine

I inherited a Zend Framework 1.11.11 site; that version dates from 2011. I'm curious about upgrading to 1.12.17, which dates from last November, but I'm not finding much documentation on how safe/easy that is. Should I even bother?

# ? Aug 15, 2016 22:01

McGlockenshire: Dec 16, 2005; GOLLOCKS!

Your best bet will be to review the migration guide:

https://framework.zend.com/manual/1.12/en/migration.html

It looks like 1.12 only contains one possibly breaking change.

# ? Aug 16, 2016 09:12

ButtWolf: Dec 30, 2004; by Jeffrey of YOSPOS

Me again with terrible understanding of anything. Refresher: I don't know php and just have to patch stuff sometimes. Its for a form on companys website that allows us to add events.

Once the form is submitted, the State location is not showing up. I have no idea where the database is so I can't check if it is even being stored. For some reason it looks like the variable is 'admin_area_level_1' for the State which is dumb.

Google drive link to the file

I see that line is commented out, but I get a 'too many bound variables' thing.

Also, if you edit an existing, the date always goes to April 8th, 2018. I have no clue what to do.

# ? Aug 26, 2016 15:27

Scaramouche: Mar 26, 2001; SPACE FACE! SPACE FACE!

The geo stuff looks like Google Maps API code, which if I remember correctly uses a lat,long and then looks up everything else based on that (including administrative_area_level_1). Problem being, there's no hard and fast representation of what that actually means. e.g. in Afghanistan it might be one thing, in Sweden another, which means in a way, that it actually doesn't mean anything.

Here's someone trying to do it in JSON:
http://stackoverflow.com/questions/8727981/how-do-i-get-the-name-of-the-type-of-administrative-area-level-1-2-etc

So I think you need to figure out where the data is coming from; it looks like a google maps API json call; if so you might have the problem the guy above does. If not Google Maps, then maybe double check whatever

# ? Aug 26, 2016 18:42

huhu: Feb 24, 2006

code:

Route::get('/', function () {
	Schema::create('art',function($newtable){
		$newtable -> increments('id'); 
		$newtable -> string('artist');
		$newtable -> string('title',500);#500 is the num of chars for this string
	});
    return view('welcome');
});

I'm watching a tutorial right now and it told me to type all this in, load the main page, and then comment everything inside the Schema out. Is this how tables are typically created?

# ? Sep 11, 2016 01:53

Adbot: ADBOT LOVES YOU

# ? May 19, 2024 12:53

McGlockenshire: Dec 16, 2005; GOLLOCKS!

FWIW whatever you're using is architecturally garbage because it's using static methods to do things that really, really, really badly need to be testable. It screams out that there's global state somewhere.

And yes, it's now relatively common for ORMs to have you programatically define the schema like that. Sometimes this is done through docblock annotations in the entity class for each row instead of writing actual code. If doing it in code seems wrong to you, but you still want the magic, you'll need to look deeper at the ORM to figure out what kind of magic it is and how to ask it to be slightly less magic.

# ? Sep 11, 2016 02:54

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > <?PHP questions that don\\'t need their own thread ?>

«‹›223 »