Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Nov 13 22:48
    crbrz opened #579
  • Nov 13 22:04
    crbrz opened #578
  • Nov 13 19:13

    jakubmisek on master

    datetime parsing fixes date_parse() for empty strings … (compare)

  • Nov 13 18:43

    jakubmisek on master

    updates to DateInterval and Dat… (compare)

  • Nov 13 15:07
    jakubmisek commented #577
  • Nov 13 15:07

    jakubmisek on master

    updates to issues with DateTime… (compare)

  • Nov 13 13:43

    jakubmisek on master

    date functions moved to "date" … (compare)

  • Nov 13 11:15

    jakubmisek on master

    date_create_immutable_from_form… (compare)

  • Nov 13 10:05
    jakubmisek edited #577
  • Nov 13 10:01
    jakubmisek commented #569
  • Nov 13 00:11
    jan-ai opened #577
  • Nov 12 23:56
    jan-ai commented #569
  • Nov 12 18:16
    howardyo starred peachpiecompiler/peachpie
  • Nov 12 15:58
    adamdriscoll starred peachpiecompiler/peachpie
  • Nov 12 14:08

    jakubmisek on master

    emitting less overloads when un… (compare)

  • Nov 12 12:05
  • Nov 11 23:02
    sergiocabral starred peachpiecompiler/peachpie
  • Nov 11 22:22

    jakubmisek on v0.9.600

    (compare)

  • Nov 11 21:17

    jakubmisek on master

    updated pcre to 1.1.0 (compare)

  • Nov 10 19:18
    InquisitiveQuail starred peachpiecompiler/peachpie
Calvin Baart
@calvinbaart
Great thanks, I'll trigger the build again
Jakub Míšek
@jakubmisek
I guess you have enabled debug build :)
Calvin Baart
@calvinbaart
Yea....I should probably have enabled it sooner (because of all the assertions I should have hit)
Daniel Llewellyn
@diddledan
only one override in WordPress now! iolevel/wpdotnet-sdk#45
Jakub Míšek
@jakubmisek
@calvinbaart should be fixed in latest commit
This message was deleted
@diddledan thanks! what is the last override? that PEAR_Error ?
Calvin Baart
@calvinbaart
Ah debug build....: https://travis-ci.com/calvinbaart/laravel-peachpie-sample
I'll try building in Release...
Jakub Míšek
@jakubmisek
well the debug build should pass as well :) so feel free to keep it, we have to fix all the assertions anyway
seems this is not an assertion btw
Jakub Míšek
@jakubmisek
looks like eval() created the same class twice
Daniel Llewellyn
@diddledan
@jakubmisek yeah, the last one is an
if (class_exists('PEAR_Error')) {
    class foo extends PEAR_Error {}
}
Calvin Baart
@calvinbaart
@jakubmisek I linked the wrong one, this was the build with the failing assertion: https://travis-ci.com/calvinbaart/laravel-peachpie-sample/builds/128209553
Jakub Míšek
@jakubmisek
@calvinbaart thanks! working on it
Jakub Míšek
@jakubmisek
@calvinbaart as I see the most recent issue is the __destruct() being called (in .NET by the Garbage Collection) and crashes
Calvin Baart
@calvinbaart
@jakubmisek Yea, I think its happening because the __destruct is not called deterministically. I think the destruct is called after laravel resets itself for the next test and then fails because its not in the state the original test expected, I'll keep looking into this to see if this is actually the case though (I can't really reproduce this easily, I'll probably disable the __destruct for now)
Calvin Baart
@calvinbaart
New assertion! https://travis-ci.com/calvinbaart/laravel-peachpie-sample/builds/128627715 Debug mode is a goldmine I guess.... :)
I'm not really sure how to report these since I can't get any of them to reproduce reliably outside of the unit test
Christopher Pereira
@kripper
Hi, how can I set global PHP variables for my web app from .cs ?
Christopher Pereira
@kripper
I found something about 'BeforeRequest'...will try
Christopher Pereira
@kripper
got it working
Christopher Pereira
@kripper
Hi, I'm stuck: require_once() is not working, altough the file was compiled
is ini_set('include_path', ...) working?
do I have to tell peachpie the root path?
Christopher Pereira
@kripper
The error says: working directory is ''
do we need to set the working directory in order to require_once() to work?
@jakubmisek any hint?
Christopher Pereira
@kripper
I think I found out how peachpie looks for the files to be included
it seems like we should always use relative paths
Christopher Pereira
@kripper
I compiled a file with <Compile Include="../modules/...
it seems like this is not supported
Jakub Míšek
@jakubmisek
@calvinbaart the assertion is a good one, will take a look. Caused by setting a value which was not de-referended by the compiler
@kripper yes the root path is crucial, see PhpRequestOptions, if not set, current working directory is used which works in most cases
Jakub Míšek
@jakubmisek

For a reference,

<Compile Include="../modules/...

is handled by MSBuild. both relative paths and absolute paths are supported. Note you can only compile files within your project folder.

Jakub Míšek
@jakubmisek
@calvinbaart the __destruct() thing - maybe we should not call it if __destruct() was already called from within the code? we might also temporarily disable the destructors if it causes compatibility issues
Calvin Baart
@calvinbaart
I don't think it has been called from the code before. I placed a log inside the destruct and its only called once (after the finalizer). I think it only causes stability issues in unit test scenarios because the test scope is pretty important for that (For example Laravel tends to destroy and completely rebuild the application after every test case to make sure the tests begin clean, I can imagine this causes issues with __destruct not being called deterministically)
unit test-like scenarios*

The following psuedo-code is what happens as far as I can tell:

SetupLaravelApplication();
{ // create new scope
    $obj = new Command();
}
DestroyLaravelApplication();

In PHP $obj is destroyed at the end of the scope, in C# its destroyed whenever (and from another thread (the finalizer thread)?) so that causes some problems

Jakub Míšek
@jakubmisek
that makes sense ... currently I have no idea how to "workaround" it, probably we should not create the Finalizer at all, only the IDisposable and implement something that would wrap the use of a local variable within a using block
so in the example above, we would actually emit a code similar to this:
SetupLaravelApplication();
try { obj = new Command(); }
finally { obj?.Dispose(); }
DestroyLaravelApplication();
BTW sadly, PHP does not have code scopes, only local and global. So it destroys its local variables on the very end of the function block (as I remember)
Calvin Baart
@calvinbaart
Just wrote some test code and BTW sadly, PHP does not have code scopes, only local and global. So it destroys its local variables on the very end of the function block (as I remember) seems to be correct. It only calls destruct at the end of the function (or when I dereference the last value, for example $obj = new TestClass(); $obj = new TestClass2();, TestClass destruct will be called here)
Jakub Míšek
@jakubmisek
Seems correct, we can keep track of a few simple cases and call __destruct() (or Dispose in our case) like PHP does. Then we'd add some assertions so we'll be notified if __destruct was not called so implementor (you and us) would know there might be an issue.
latest commit disables finalizers
Daniel Llewellyn
@diddledan
You may remember ages back I mentioned that adding the code-based AppInsights thing from azure to a wpdotnet was causing exceptions to fire. I finally took some time to figure it out - it's in the WPdotnet cache mechanism which saves the headers of the response when adding to the cache and then tries to re-add those headers in a cached response. The response therefore tries to add a second Request-Context header because AppInsights adds one to every response before wpdotnet then adds the one from the original caching request
I worked around it by adding an if (header.Key != "Request-Context") {} around the re-adding mechanism when serving a cached response
it might be better to not cache the header in the first place rather than avoiding it when emitting the cached responses
        async Task WriteResponse(HttpContext context, CachedPage page)
        {
            foreach (var header in page.Headers)
            {
                if (header.Key != "Request-Context")
                {
                    context.Response.Headers.Add(header);
                }
            }

            await context.Response.Body.WriteAsync(page.Content, 0, page.Content.Length);
        }
^^^^ From my edited copy of PeachPied.WordPress.AspNetCore/Internal/WpResponseCaching.cs
LORDofDOOM
@_LORDofDOOM__twitter

Hi Guys,

first of all, it's a really great project and I'm already able to build wordpress with some plugins :-) Just some questions (i hope this is OK in this chatroom):

  • Is there any option to compile wordpress plugins directly from the wordpress folder (like themes, without create a separate plugin and reference it), the idea here is that I want to be able to create a compiled assembly from a "normal" Wordpress installation and check if plugins will work) ? I've tried to simply copy some plugins to that folder, it also seems to get compiled but I dont see them in installed plugins.

  • You write in the Wiki that e.g. elementor is supported, I've also get it compiled but it dont run in debug mode (throw exceptions because of Logging) and in release mode it runs but I'm not able to use it (type error on save) - Did you manage this plugin differently (in terms of compiling), and if so, is there any repository for it ?

Jakub Míšek
@jakubmisek
@diddledan thanks! I'm not aware of AppInsights but we should definitely not cache certain headers