Thank you Mamba

I will do so because I think that the data is not sent from the file tables.php

Code of case 'save':

Be aware that the coding error I pointed out is still in place and you need to address the use of $datas[]...

Should just need to remove the []'s.

Otherwise when you get to the foreach loop you will go through every instance of $datas that is currently in memory. So the first time you will iterate through just one value of $datas but the second time you will have the same value as you had the first time as well as the new second value and the third time through will have the first two and an additional. Plus when you send your array to setVars you will have the whole array you just setup sent to it instead of each item.

Removing the []'s should get the foreach loop to work as intended.

Should step through the contents of $datas and send each entry to setVars.

Rodney

As you say is right, but I think some tests, there are no data in global variables.

I think have not been gone from the data file tables.php, to file fields.php and then the same data compiled in the form class/fields.php are not loaded, however, in the same file admin/fields.php

Other tests conducted with the NetBeans IDE, some variables are empty.
The only solution, I think is to integrate a class session, to ensure that these data can not be erased in the global variables GET/POST/REQUEST.

In older versions of the module are the same for both cycles in class/file and admin/file, the only difference is that the data is passed from one file to another, compared to the old one that used only the file tables.php

If you noticed, the publisher module uses its own class session to store the data and then save them in the database.

I also added two class files, request.php and helper.php to pass global variables, but still does not always work as well as the functions modulename__CleanVars ($ _REQUEST , 'id ' ) ;

In short there is to study well first and then work

Ok, About variables...

Get/Post are sent within the page. With a GET being installed in the URL and being limited to length and POST being displayed in the HTML text.

Cookies are kept within the browser and can be stored for just the current session or for longer depending on how it is setup.

These methods require the information to be stored on the client computer and can be modified or created by a user with or without malicious intent.

A global variable that is accessed through a GET or POST has to be sent every time a page is refreshed and a cookie can be disallowed if the users browser is set to do so.

REQUEST is a lazy way of accessing variables. It will grab the variable from GET, POST or COOKIE and if there are more than one place the variable is located it will prioritize which one to use. This is considered an INSECURE variable and should not be used in a production site. A malicious user could over write an intended value by setting a value in a higher priority location which would over write the valid data.

All of the above mentioned methods should always be checked for malicious content since they can be spoofed by a malicious user.

SESSION data is server side and the user never has direct access to this information. It stays with a specific session and you have to insure you use the session_start() function to access the data when your page starts. The information stored within the SESSION data will remain through out the session so you have to insure you remove it after you are done with it. From what I know session data should be considered to be secure since it is stored on the server and the client has no access to it.

So yes, for a variety of reasons using session data would be a good idea. I was converting the install pages to using session data when I was working on it and it was also much faster. I have not run across any reason NOT to use session data but have for the reasons mentioned above for the other global data types. They each have their place.

Rodney

It's true what you say about security.

In any case, the module in question works only locally, at least from what I see and I do.

This module would have no meaning for the time to install it on a remote server.

In a local server you can make any changes you want.

I Sending files, that mentioned earlier, in svn

if you want to take a look at the code.

It was very simple

It was enough to remove the foreach loop, and instead use an array datas with setVars(), used directly the setVar() function for each variable, and checks on the same variables with isset

View the file in svn

Cool. Great that it worked for you. I wasn't sure if you could pass an array like that to setVars or not.

Hope my input helped you progress.

Only wish I could have been more help.

Rodney

Even if none of you has been technically help, I'm glad I shared the idea with you

It helped me to understand that I had to go back to the basis of the studies php.

In fact, rebuilding all the work behind it, with mysql, php and a simple form, I created a mini, mini, mini, cms, "please let me get through these words" , I was able to rebuild all the code necessary and is enough to cancel rather than add another code.

Great, is it?

Thanks anyway for having contributed to the idea at least.

For this reason, I have now created a tutorial that explains how you can do it in a very simple way, a script, which through a simple form, send the data to the mysql database mode multirows with php