LostKobrakai

Yeah, for nested pages in the trash this might be easier, but you could always construct the path manually as well. I'm just not so keen on actually changing anything of the trashed status without actually needing to change it.

If it's working it's ok. If you want to rely on core functionality I'd rather ask Ryan to extract the regex parsing to a separate function so it's useable by us as well.

I'm not sure if it's meant to be used like that. But you can certainly strip out the data parsing to get the data you need.

It's true that class collisions can happen, but pw 3.0 is moving to using namespaces for that reason. In turn variables are not namespaced. They are always bound to the scope or global. Wanze's helper method is probably a better way to go, kinda like extending Wire to get access to api variables in classes.

All the information is included in the trashed page's name. Otherwise there wouldn't be the option to restore trashed pages with the click of a button. It's just, that there's not a nice api present around that.

Because it breaks as soon as you're using any external code that uses these variable names anywhere. The WirePDF module for example does use mpdf as pdf rendering library. If this library is using $page as variable somewhere it's break your website. @Mike It's using the same object but it's still repetitive to use this snippet in each function or rewrite code from using variables to wire("var") when it's abstracted into a function.

I'm currently short on time, but I noticed my date selection code in there and I've seen a better selector for that from ryan some time ago: // select anything overlapping the range of $start - $end $selector = "enddate>=$start, (enddate<=$end), (startdate<=$end)";

I'm not sure if it wouldn't be confusing to have pages sorted in the pagetree in another order than "sort=sort" if manual sorting is used.

It's really useful for that exact use-case, but sometimes it can also be nice when you need to get a field value without textformatters being applied or other kinds of output formatters.

Unix timestamps do start in 1970. All times / dates before that can therefore not be translated to a timestamp and not be saved. I'm just not sure, why it's saving a date for 1902 correctly. Edit: Ah php does work with negative integers as well. The max size for an integer (32 bit) would be -2147483648 which translates to 1901/12/13 20:45:52. So maybe it's still an issue with not being able to translate to a timestamp.

Set the format to a sensible default and use this in the frontend to get the timestamp for other formatting purposes: // 1452082822 $timestamp = $page->getUnformatted("dateField"); // 01/06/2016 12:20 $defaultFormat = $page->dateField;

And implicitly that does also mean that with the first setting (blank == 0) you cannot save a value of 0 for that field. It will then be treated as empty and not save the 0. Therefore a default value of 0 is the same as empty.

I'm not sure if setting the timezone for php is really the most sane way to go about it. I'd rather keep php's timezone to be consistent and just use a library like carbon to handle the timezone differences for the frontend. Edit: Just read that you need it for the backend as well, so that's not so much an option.

Save the base64 data as decoded file to a temporary place (e.g. /assets/cache/) and then just add it to the file field and it will be copied to the correct path.

Maybe not exactly a use-case for adding additional pages, but I'm using two separate pagetables to hold applications and fully accepted applications. The pages are just moved from one to another when a application is accepted and applications can only be added to the pagetable holding the non accepted ones.

I just noticed, that this might actually be a great option for packing offline, html+js only apps for clients (e.g. localstorage needs an server to function). Just let them double-click the thing and it's working.

PageArrays are internally just simple arrays and that code is retrieving that array, sorting it to fit the order of the stored id's and then setting it back to the PageArray. How usort works is quite nicely described in the php docs.

I'd create a function, where you pass in the page and it returns the meta data. In the function I'd simply use a switch statement to change up the output depending on the template. With that you can have nice defaults, but also the option to customize when needed.

$journeyArray = $journey->getArray(); $idArray = explode("|", $session->journey); usort($journeyArray, function($a, $b) use ($idArray) { $keyA = array_search($a->id, $idArray); $keyB = array_search($b->id, $idArray); return $keyA < $keyB ? -1 : 1; }); $journey->setArray($journeyArray);

Merges do (or at least should) always create an commit, but if there's nothing to merge (just new additions) the master branch can be fast-forwarded to the dev branch state without an commit. But most git apps I've used by now do fast-forward automatically if possible.

trackChanges does need to be active. Not sure if that's the case when creating a new user.

There's certainly something fishy going on. I've xdebug running with max nesting of 300 and never had a problem (the default 100 is to few) and I'm using custom user templates as well.

To put some light on the differently shaped symbols you're describing: The straight ones are from an typographically background not even quotes, but unit-symbols " for inch or arc-minute and ' for arc-second. The slanted ones you're describing are the typographically correct symbols for quotations and are most of the time formed like commas. As TextEdit is not a code editor, but a simple text writing tool it can be the case that quotes are automatically converted to the correct ones, which, as you noticed, do not work in code as they are other symbols. For those questioning, why correct quotes are most of the time not even on the keyboard layout, that's a remnant of the time of typewriters, where space, material cost and letter distribution where driving the keyboard layout evolution. Typographic correctness just wasn't valued as much as those other issues. Edit: For code editing I'd suggest using dedicated software, which won't make any automatic typography replacements and sometimes even highlight such errors.