Jump to content

olafgleba

Members
  • Content Count

    9
  • Joined

  • Last visited

Community Reputation

2 Neutral

About olafgleba

  • Rank
    Newbie

Profile Information

  • Location
    Cologne, Germany

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. FYI, i got in touch with the hosting support. It turned out that my first suspicion was kind of right. The PHP version on the staging environment was actually not 7.0.33 (as shown in the hosting backend) but a old 5.6.x. And that causes the problem. Switching to PHP 7.x.x solves it.
  2. @elabx Yes, it does fail whatever length the strings has. On whatever pages. Pointing to mod_security is maybe helpful. I dig into this. I remember having some issues some time ago also (no related to this topic). Thanks for you suggestion!
  3. Hi, maybe kind of related to https://processwire.com/talk/topic/13286-image-description-not-saving/ but with other environment bits. While adding a new page/edit a existing page containing a image field, the image itself gets stored into the database but strangely the entered description does not. More strangely this only happens on my staging server. Within my local dev environment all is fine. And beside of this particular problem, all parts of the PW instance works fine. On both environments (s. below). First suspicion was the varying PHP/mysl versions of the local <-> staging environment. But, there are many working projects with the identical setting (s. below). And i never encounter this problem so far. No error/log/console output. It just fails to get stored. Local Environment: PHP 7.4.6, mysql 5.7.29, PW 3.0.148 Staging Environment*: PHP 7.0.33, maria DB 10.1.46, PW 3.0.148 Maybe someone has a hint what to try? Thanks in advance. *) I cannot change the staging server php/mysql settings because its part of a shared hosting account.
  4. That gives me the expected result (just like the output of a field with the default `datetime` Fieldtype). echo $return->getUnformatted('programm_date_advanced') // e.g. `1562233140`
  5. First, thanks for your effort making this extension! Environment: DatetimeAdvanced v1.0.4, PW 3.0.148, PHP 7.4.6, mysql 5.7., Timezone ist set. While accessing subfields as selectors within a $pages-find() works fine, i am having trouble using subfields within PageArray results. Definitely i miss something here. Maybe i should stop working for today, but meanwhile someone maybe have a hint what i am doing wrong... Thx, Olaf <?php foreach($results as $result) { // Directly access gives me "Notice: Trying to get property 'year' of non-object" echo $result->programm_date_advanced->year; // strftime shorthand gives me "Fatal error: Uncaught Error: Call to a member function strftime() on string" echo $result->programm_date_advanced->strftime('%Y'); // Using strftime plain gives me "Notice: A non well formed numeric value encountered" echo strftime('%Y', $result->programm_date_advanced); // Using strftime unformatted gives me "Warning: strftime() expects parameter 2 to be int, object given" echo strftime('%Y', $result->getUnformatted('programm_date_advanced')); // Plain output is o.k. echo $result->programm_date_advanced; // e.g. 10.07.2020 } ?>
  6. I absolutely agree. Currently the synchronisation is in development and testing. The database (or better said, the distributors API) only provides a very narrow set of interrogations. And has some strange data field types also (e.g. row modified is delivered, but internaly stored as a string type in a unusal format). So the create/delete of pages every import is just for testing purposes. If all is set and stable (and i can rely on the DB modified field), your approach is definitely the way to go. The questions (page ID limitation? Reset...) came up while testing. And i was curious about it 😉 Thx for you answer (also to @rick) Olaf
  7. Hi, in my current project i synchronize a thirdparty database (job advertisments) with my PW Instance every night. To reflect all possibly modified/added/deleted data sets it is mandatory to delete the whole set of related pages (page <=> database row) and rebuild all pages again every sync. So the page IDs increases constantly every run. I wonder if this could get me into trouble in long term. Is there any restriction of page ID values? That leads me to a related question. When i build pages through the PW API, is it possible/meaningful to maybe reallocate a (temporarily saved) ID of the deleted pages to the new build pages? To avoid the incrementation... Thanks for your thoughts in advance. Olaf
×
×
  • Create New...