www.wysiwygwebbuilder.com

Hi,

8 hours ago I bought and installed the paid version of MySql CRUD (thanks Pablo).
I installed the extension files per usual instructions and restarted WWB17.
Dragging the MySql CRUD to a WWB17 page now displays 'MySQL CRUD (Create-Read-Update-Delete).

Created a test page and set it up. Both views appear and I can delete a record.
However, Search, Update and Add don't work. Web browser inspect source gives no clue, as far as I can determine.
The database itself has been in use for years via the PHP Blog extension without issue so its difficult to consider any r/w attribute issue.

A stripped down test page can be examined here: http://146.200.252.30/ParBeach/page1.php
and without Summernote HTML editor here: http://146.200.252.30/ParBeach/page2.php

You may have to ignore the non https warning to proceed..
The links will only be live for a few days.

I'm irritated with myself as clearly its something I'm not doing or doing it incorrectly but I'll be darmed if I can find out what it is.
Any assistance gratefully received.

Regards

Sam

Are you sure the primary key is correctly configured in the database?

Hi Pablo,

Thanks for the speedy reply.

Yes. I've just re-checked in response to your question. first field 'id' INT(11) AUTOINCREMENT PRIMARY KEY

Then maybe the permissions of the database are not correct?

The database itself has been in use for years ...

That's a good start... knowing that the database itself was working fine, BUT you were using a different extension to 'talk' to it.

What is different? Have you set up a new user, and given that user full access? Something 'simple' is being overlooked. You are using the correct credentials to view the database, so that part is working. It still sounds like 'permissions' to me, so verify what rights the new user has.

Thanks for the responses Pablo, MGD4me,

I would also suspect a permission issue were it not for the fact, as mentioned, that a Delete is successful. You are welcome to try that on my test site yourself.

The database is still in use with PHP Blog and still successfully CRUD's with exactly the same user and permissions.

The intent is to migrate from PHP Blog to MySQL CRUD for the administration of the blog.

Short of building a new database, any other ideas?

Cheers

New database with just two fields including the primary key.
New user.
New permissions.

and I'm getting exactly the same results.

I'm using PHP7

Now I'm really confused.

http://146.200.252.30/ParBeach/page3.php

In PHP7 I've set the new database with just two fields and two records to allow the user access with password.
Same result as before.

Then I set the database to allow user access without password.
Same result as before.

Privileges for the user are set to Global All

I've also copied the test page and required components onto the live website (commercial) server.

The results are the same as my test rig.
Read works (both views)

Delete works.

Nothing else.

Are there any messages in the PHP error log on the server?

Hey Pablo,

Thanks for sticking with this. I appreciate it.

Currently no error.log being generated - but this particular server does seem to take a fair few minutes to refresh and show any error.log file.
I'll keep playing to see if one appear.

Can't do a deletion- I'd get into trouble....

Sam

Pablo,

No error.log being generated.

Since I'm looking on the remote commercial server, I can see, when I click on SAVE, the page blanks for a milliseconds and then refreshes but this time without any editing I attempted to enter. In other words, reverts to the original record and ignores any edits.

Sam

No. Confirmed. No error.log being generated.

I added a new record on the live site for a few seconds (using the 'live' PHP Blog extension admin page).
And then using the test page of MySQL CRUD on the live site successfully deleted the same record.

But again, no other function (aside from Read) works on MySQL CRUD, on the live site.

Sam

I would have thought the error_log file would be created immediately any errors are found. That's how mine works.
Perhaps the PHP default in the php.ini file is not to report errors.
To ensure errors are reported for this project you can add the following code at the Start of Page using e.g. an HTML object.

<?php
error_reporting(E_ALL & ~E_NOTICE);
?>

It may also need the php.ini file options:
log_errors = On
error_log = error_log

Hi WWBman,

Most definitely the servers are set to report PHP errors.
I don't think my websites could have been accepted commercially were it not for the log catching my development errors and giving me the information about where I was going wrong before going 'live'.

But thanks for thinking about it and contributing.

Same

I'm using PHP7

Are you using 7.0 exactly, or 7.2. 7.3, etc??

I would try 7.0 if not already, or go back to 5.6 just for testing. Grasping at straws, as you can tell...

MGD4me ,

I'm using PHP 7.3.12.r121

The commercial server in question, I don't know the precise version but the administrator did upgrade from 5.6 to 'a' version of 7 in March this year.

I had thought sleeping on the issue would provide a light bulb moment. Alas, not to be. However, I do intend to restart from the very beginning including a fresh database to see if I made an assumption where I shouldn't have.

Thanks for helping.

FWIW:
My project has PHP5-PHP8 in Page Properties > Advanced
My server uses PHP 7.3.33

MySQL CRUD 1.0.4

What does your host say about this?

Hi Jerryco, WWBman,

I'm been updating MariaDB and also phpMyAdmin to ver. 5.1.1, on my own server and retesting.

I've not bothered the company hosting the live website just yet.
I have uploaded my test page and associated components to the live website. The host server has replicated the exact same issue as on my own home server and without generating any errors in error.log.
What this tells me is that I can replicate the issue on someone else's server so my issue is unlikely to be within the configuration of my home server. Nevertheless I am updating everything in my home server that might impact the web server.

The host server of the live website is not my host. I do not have cPanel access with admin rights.
The live website works just fine and with the blog database I wish to upgrade.
My issue is in the process of updating the live website, on my home server. I've tested as much as I dare on the live site without raising any flags by damaging the live system. I need to cure the issue on my server and then publish to the live site. Replicating the issue has narrowed where the issue might lie - but I'll be darned if I can think where it has narrowed to!

Thanks for your input though. I appreciate it.

Sam

I don't understand what you did with this comment:

To ensure errors are reported for this project you can add the following code at the Start of Page using e.g. an HTML object.

<?php
error_reporting(E_ALL & ~E_NOTICE);
?>

It may also need the php.ini file options:
log_errors = On
error_log = error_log

The code is just to ensure errors are reported in the error_log file.
The default "error_reporting" value in the php.ini file may suppress errors being reported.
The code will override the default value for this project.

I did partially answer your question when I wrote "Most definitely the servers are set to report PHP errors."

I agree I wasn't specific enough. php.ini options are set as you suggested on the servers. However, I have not yet modified the relevant pages to include your suggestion. Yet.

It's just possible I may have stumbled on a potential clue to the issue.
I note that moving the pointer on the buttons EDIT, DELETE and pagination plus all the field headings respond with the pointer changing to a hand. It also shows up the link details at the bottom of the web browser.

Moving into an editable field changes the pointer to a carat.

However, moving the pointer over the ADD, SAVE, CLEAR and OK (for search) produces no link information at all and the pointer does not change.

This may or not be relevant. Much of me thinks it is irrelevant but just in case I decided to mention it here.

Sam

Jerryco,

Start of page included your
<?php
error_reporting(E_ALL & ~E_NOTICE);
?>

Republished. Clicked all the buttons on both views (list and edit).

No error.log generated.

Thanks for the suggestion. I hadn't thought of doing that until you first mentioned it. Another narrowing of where the solution might lie.

Sam

Okay.

Here is the TLDR solution: the WWB file for this particular project is corrupt. Loading up WWB17 as a new project and re-creating the same test MySQL CRUD page works as intended (as far as I've currently tested but no reason to think it will fail again).

Curiously, nothing else seems broken with the newly discovered corrupted project file and the entire website republishes without error, on my server - except for the new extension.

Any suggestions as to the quickest, least effort to create a new project and import the pages from the corrupt project file without copying over whatever is causing the corruption?

Many thanks for all who contributed. Hindsight is a wonderful thing. Shame I can't bottle it for re-use. I <should> have created an entire new project to test the MySQL CRUD extension in the first place. Ah well, lesson learned.

Kind regards,

Same

Can you 'import' all the pages from the odl to the new? That may reset whatever is corrupt.
[right click over on site manager and select 'import page from another project'. Then ensure you tick all the pages you want to import].

Alan

Hi Alan,

Yes. I tried that but it imports whatever is corrupting along with it.

I'm currently importing one page at a time, re-publishing and re-testing MySQL CRUD, import next page and so on, until all pages are loaded and/or one or more page starts the corruption and I tag that page(s) as requiring a re-build from scratch.

Laborious but cannot think of any other easy route.

Thanks for your suggestion, though.

Sam